很多网络工程师面对琐事之一是SSL证书的维护和更新。对于笔者而言，SSL证书主要是用于VPN部署，但也有很多网络设备需要证书来加密客户端到服务器的通信。每当笔者声称需要一个证书时，大家都会变得鸦雀无声，可能对于大多数人来说，证书有点恐怖。毕竟很多使用公钥加密技术的现有资源要么处于“保密”状态，要么使用对于实用主义来说过于抽象的原则。本文的目的就是解决这方面的困惑，介绍SSL证书的基本知识和一些常见的现实例子。
SSL证书的基本知识
Web服务器和相关设备使用的常见证书主要由三部分组成：
• 主体私钥。这包含关于主体的独特的可识别信息，这通常是Web服务器，但也可能是个人用户。私钥通常在主机本身上生成，理论上永远不会离开操作系统密钥存储区。在生成私钥时，也产生了一个证书签名请求。
• CA公钥：证书颁发机构(CA)是各方信任的一台服务器。现在有很多证书颁发机构提供证书服务，例如DigiCert或者VeriSign。此外，这可能是私人CA，例如微软Windows Server操作系统中的CA。如果在连接客户端(无论是Web浏览器还是操作系统本身)的证书库中存在其公钥的副本，则该CA被认为是可信的。
• 主体公钥。当CA对从私钥生成的CSR文件中的信息签名时，将会产生公钥。该公钥被设计为被透明地传输，并包含验证真实性和验证使用方法(例如服务器或客户端身份验证)的签名。
当我们的主体服务器接收到连接请求时，它将会出示其签名的公钥，以便客户端可以验证其身份。如果客户端信任我们的公钥，就会考虑加密，而公钥将被用于加密客户端的会话密钥。这个会话密钥只能由我们的私钥进行解密，并且可以完成其余安全套接字连接。
通配符证书
在创建私钥时，公用名(CN)将被指定，在大多数情况下，这是主机的完全合格域名(FQDN)，例如www.foo.com。如果很多服务器需要保护，更经济且更实用的做法是对给定域的所有数据创建通配符证书(wildcard certificate)。当你在逻辑主机(例如负载均衡器)上需要多个虚拟身份(例如www.foo.com, mail.foo.com以及ssl.foo.com)时，这也是非常有用的。在密钥生成时，并不是为特定主机使用单个FQDN，而是主机部分被通配符取代，例如*.com。因此，该证书对于DNS域的所有事物都是有效的，但并不包括所有子域。大多数现代客户端浏览器支持通配符，但你可能会碰到少数例外，例如嵌入式浏览器或早期版本的IE浏览器。
主机备用名称
一个相对抽象但很有用的功能是主体备用名称(SAN)。如果你需要通配符证书的功能，而又需要来自传统客户端的连接，一些CA会使用一些有效的备用名称来签名主体公钥。即使是老旧的客户端SSL部署也支持这个功能，这允许主体公钥域这样替换名称：
• CN = *.foo.com
• SAN = www.foo.com, mail.foo.com, ssl.foo.com
即使客户端不明白主体通用名称中的通配符，它还是会匹配一个备用名称并接受该证书的有效性。
中间CA
绝大多数客户端证书不是由根级CA发出，而是由中间证书颁发机构(intermedia CA)发出。从本质上讲，根级CA对中间CA的公钥进行签名，允许其代替它签名证书。这种授权签名可能会发生几次，你最后得到的证书可能经历了几层证书机构。在下面的例子中，主体的证书“www.amazon.co.uk”由VeriSign Class 3 Secure Server CA-G2签名，而这又是由VeriSign根证书来签名的。
常见的中间级证书被嵌入在客户端证书存储区，但很多来自互联网服务提供商或域名注册商的合法中间证书并不是这样。中间证书需要被连接到Web服务器，这样客户端就可以循着证书链直到找到由可信CA签名的证书。在笔者的经验来看，这解释了为什么当用户连接到有付费证书的网站仍然遇到证书信任错误的原因。证书颁发机构提供根和下属公钥的捆绑，你需要将其导入到Web服务器配置。很多CA提供在线工具来检查中间证书是否被正确安装。当导入你的签名公钥时，你有必要检查中间证书是否需要注意避免必然的支持呼叫。
证书管理
OpenSSL加密工具包是工程师管理证书的“秘密武器”。这些二进制文件被包含在大多数*nix版本中，同时，也可用于Windows。这个强大的工具很值得我们学习，这样我们就不需要记住多个平台的本地证书管理的细微差别。精简版本就能够满足大多数日常需求。
微软.PFX文件捆绑密钥
PFX文件主要用于微软环境，在通常情况下，密钥在Windows中生成，然后由域集成CA自动对其签名。这是有用的，因为这个私钥、签名的公钥和CA公钥被捆绑成单个文件。这个密钥可以选择通过密码来加密，当你在公共网络传输证书时，这可以提供某种程度的保护。通过使用OpenSSL，单个组件可以被导出和转换。此外，这些文件不包含人类可读部分。
PEM和DER编码
常见x.509v3证书通过两种格式编码：PEM或者DER，并且通常会被授予.CRT或者.CER的文件扩展名。这些文件扩展名本身并不会让你知道它们的格式，因为它们是互换使用的，但其内容可以给你一些提示。PEM文件是Base-64 ASCII编码，前缀为“---- BEGIN CERTIFICATE ----”，后缀为“---- END CERTIFICATE ----”。DER文件是二进制编码，不是人类可读的。
当从Windows导出证书时，你可以选择三种格式：DER、PEM和P12，但是具体使用哪种并不清楚。
很多网络设备需要证书和密钥以PEM格式导入，但Windows MMC证书管理单元只允许私钥以P12格式导出。这仅仅是成功的一半，因为你还需要提取签名的主体的公钥。
从PEX文件以PEM格式提取公钥
导出的主体公钥清楚地显示了发出该公钥的服务器的名称，以及签名该公钥的根级CA的名称。你必须检查你是否在操作正确的证书(例如由商业CA而不是内部域CA签名的证书)。
为了逆转这个过程，并将私钥，公钥和CA证书结合成单个文件，你需要使用以下命令：
C:\cert>openssl pkcs12 -export -out NewPfx.pfx -inkey justPrivateKey.key -in justPublicKey.crt -certfile CACert.crt
加载“屏幕”到随机状态—完成
输入导出密码： <设置新密码>
验证导出密码： <重复新密码>
PEM和DER之间的转换
另一种常见的要求是转换PEM编码的文件为DER编码：
C:\cert>openssl x509 -outform der -in justPublicKey.pem -out justPublicKey.der
然后，将其转换回来：
C:\cert>openssl x509 -inform der -in justPublicKey.der -out justPublicKey.pem
值得注意的是，这个过程通常会去除纯文本扩展属性，只在“---- BEGIN CERTIFICATE ----”和“---- END CERTIFICATE ----”缓冲区之间剩下原始证书。
解决证书管理问题
不可避免的是，你将遇到某些东西无法正常运行的情况。如果遇到这种情况，第一个步骤是使用OpenSSL的本地工具来检查你的密钥和证书的格式是否正确。
检查私钥文件：
C:\cert>openssl rsa -in justPrivateKey.key –check
检查CSR：
上面的例子清楚地显示了整个证书主体。这里的两个密钥组件是“O=”(Organization企业)和“CN=”(Canonical Name，规范名称)。企业字段中必须与你的注册机构名称完全相同。例如，如果你公司注册名称是“Foo Company Plc(UK)”，如果你提交“Foo Company UK”将会被拒绝。此外，证书中指定的域名必须是由你或授权第三方注册的。
验证证书(PEM或者DER格式)：
C:\cert>openssl x509 -in CACert.crt -text –noout
在下面的实例中，笔者分析了VeriSign CA公钥，可以从中收集很多有效信息：
• 证书有效日期。所有证书在其需要重新签名前都有一个有效性窗口。Web服务器证书的有效期一般为不超过三年，而CA证书往往是10年或以上。一个没有经验的网络管理员可能会通过有效期为一年的证书来创建域根级CA。在这种情况下，CA根证书很快会过期并失效，即使签名的证书的有效期更长。
• 密钥强度。RSA密钥有给定的强度：使用的位数越多，就越难以猜测。很多公共CA现在只签署2048位密钥，但是，1024甚至512位密钥用于内部应用程序的情况也不少见。
• 密钥用途。除非你是做一些模糊的事情，否则至少这应该包括传输层安全Web服务器身份验证和TLS Web客户端身份验证。
• 证书吊销列表(CRL)和在线证书状态协议(OCSP)分发点。一些客户端会对证书进行更多的实时检查，以确保它们没有通过使用静态CRL或者动态OSCP协议被吊销。公共CA对这些服务提供公开访问，但私有CA可能没有对这些服务正确地配置或者不允许远程客户端访问。
• 主体备用名称。正如前面所讨论的，SAN允许证书拥有几种不同的身份证书。所有配置的SAN也许可以解释为什么主体名称明显不同时，证书也可以通过验证。
