[分享] GitLab SSL/TLS加密的那些事

官方技术分享
, ,
#1

首先需要说明的是，通常情况下我们都会为了更安全的访问实例为自管理的实例配置 SSL 加密，常用的需要配置 SSL 加密的地方主要有以下：

  1. gitlab 主示例的访问
  2. registry 镜像仓库
  3. pages 访问

  • 证书的位置
    每种配置都可以指定证书的位置，在未指定的情况下，默认存放于/etc/gitlab/ssl目录下，也就是说如果不想配置指定证书的参数，可以按照指定的格式将证书放置在上面的目录下。格式规则如下：

    # 主实例
# nginx['ssl_certificate']  # gitlab.example.cn.crt
# nginx['ssl_certificate_key']  # gitlab.example.cn.key

# registry
# registry_nginx['ssl_certificate']  # registry.example.cn.crt
# registry_nginx['ssl_certificate_key']  # registry.example.cn.key

 # pages
 # gitlab_pages['cert'] = "/etc/gitlab/ssl/#{Gitlab['gitlab_pages']['domain']}.crt"
 # gitlab_pages['cert_key'] = "/etc/gitlab/ssl/#{Gitlab['gitlab_pages']['domain']}.key"

    在未指定位置的情况下，都可以以<domain>.crt / <domain>.key的方式存放于/etc/gitlab/ssl目录下。

  • 证书的格式
    有多种类型的证书格式，最常见的三种格式是 PEM、DER 和 PFX。

    PEM（P\r\ivacy Enhanced Mail）格式是最常见的证书格式之一。它是基于 ASCII 编码的文本格式，可以包含证书、私钥和其它相关信息。PEM 格式的证书通常以 .pem、.crt 或 .cer 作为文件扩展名，私钥则以 .key 或者 .pkey 作为文件扩展名。此种为 gitlab 常用的证书类型，如果是阿里云生成的证书直接下载 nginx 证书即可。

    DER（Distinguished Encoding Rules）格式是二进制格式，通常以 .der 或 .cer 作为文件扩展名。DER 格式证书通常使用在 Java 平台和基于 Windows 的应用程序中。这种格式的证书不能包含私钥。

    PFX（Personal Information Exchange）格式是一种二进制格式的文件，同时包含证书和私钥。PFX 证书通常以 .pfx 或 .p12 作为文件扩展名。这种格式的证书通常用于导入和导出证书、私钥和中间 CA 到 Windows 操作系统中。

    除了这三种常见的格式，还有一些其他的证书格式，如 PKCS#7、PKCS#12 和 JKS（Java KeyStore）等。不同的证书格式适用于不同的应用场景，可以根据实际情况来选择合适的证书格式。

  • 证书的类型
    以下是常见的 SSL/TLS 证书类型：

    1. DV（Domain Validation）证书：验证申请 SSL/TLS 证书的域名是否合法，通常在一个小时内便可以完成。DV 证书没有企业身份验证，只提供基本的安全保护。

    2. OV（Organization Validation）证书：OV 证书除了验证域名是否合法外，还会进行企业身份验证，需要提交公司相关材料进行审核。OV 证书可以提供更高级别的身份验证和保护。

    3. EV（Extended Validation）证书：EV 证书是一种高级别的 SSL/TLS 证书，提供了最高级别的身份验证和保护。EV 证书需要经过更加严格的企业身份验证，并在浏览器地址栏中显示特殊的绿色锁图标，通常被用于金融机构等对安全性要求极高的企业。

    4. Wildcard 证书：Wildcard 证书允许在同一个域名下保护所有的子域名，例如 *.example.com 即可以保护 www.example.com、mail.example.com、blog.example.com 等所有子域名。

    5. SAN（Subject Alternative Name）证书：SAN 证书允许一个 SSL/TLS 证书保护多个域名，可以在申请证书时将多个域名添加到证书的 SAN 字段中。

    每种 SSL/TLS 证书类型都有自己的优点和适用场景。常用的有 DV 、Wildcard 和 SAN 类型的证书。

  • 证书受信
    在申请使用证书时，建议使用受信证书，不受信任的证书在后面使用 geo 或者集成时会遇到很多信任的问题，如果仅是在单实例中使用，也是可以接受的。如果您是不受信任的证书，请参考。

    那么如何判断整数是否受信任呢？

    方法1：检查证书发行机构是否在各大操作系统和浏览器的信任列表中。这些信任列表包含了受信任的证书发行机构列表，可以通过其中一种信任列表来检查证书是否受信。如果证书的发行机构在相应的信任列表中，那么这个证书被认为是受信任的。

    方法2：验证证书的数字签名。数字签名是由证书发行机构使用其私钥对证书进行加密的结果。如果某个证书的数字签名可以被证书发行机构的公钥解密，并且解密的结果与证书本身匹配，那么证书就可以被确认为受信任的。

    需要注意的是，数字证书的信任只是建立在证书发行机构的信任之上。因此，证书发行机构本身的信誉和安全，以及证书私钥的安全性都是确保证书受信任和安全的重要因素。

    此外即使是受信任的证书也可能出现再内网中不受信任的情况，在验证证书的有效性时，需要访问由证书颁发机构提供的在线证书撤销列表（CRL）或在线验证协议（OCSP）来确定证书是否被撤销或者是否存在其他问题。因此，在验证证书时需要联网。

    但是，如果证书已经在本地缓存中或者本地信任列表中，可以在没有互联网连接的情况下验证它的有效性。因为本地缓存中的证书已经经过本地计算机的验证，并且被认为是受信任的证书，因此在没有更改或吊销的情况下仍然是受信任的。但是，缓存在本地的证书如果被吊销，或者在本地计算机上存在对它的更改，那么验证它的有效性时需要联网从而可以访问到在线的证书撤销列表或者在线验证协议。

  • 单域名证书、通配符证书和泛域名证书
    单域名证书、通配符证书和泛域名证书是数字证书中常见的三种类型，它们的区别主要在于可保护的域名范围。

    1. 单域名证书：只能用于一个具体的域名，即用于证书申请时指定的域名，比如 www.example.com，只能保护相应域名下的所有子域名。

    2. 通配符证书：可用于保护一个域名及其所有子域名，通配符指的是通配符字符“*”，可以替代任意字符，用于匹配所有子域名。例如 *.example.com 可以用于保护 www.example.com、test.example.com、abc.example.com 等所有 example.com 的子域名。

    3. 泛域名证书：可用于保护一个域名的所有子域名以及所有级别的子域名，包括二级子域名、\三\级子域名等。泛域名指的是用星号代替主域名。例如，*.example.com 可以用来保护 www.example.com、test.example.com、abc.test.example.com 和 xyz.abc.test.example.com 等所有层级的子域名。

    综上所述，单域名证书只能保护一个域名，通配符证书可以保护一个域名及其所有子域名，而泛域名证书可以保护一个域名及其所有层级的子域名。所以在选择适当的证书类型时，需要根据自己的需求和预算来决定。

  • Fullchain 证书
    fullchain证书是一种包含完整证书链的证书文件，一般包含实体证书（domain name certificate）和证书链（ca bundle）。其中实体证书是由证书颁发机构（CA）签发的数字证书，证明了该域名或者网站的身份，而证书链则包含了CA证书及其父证书链。因为大部分计算机上都已存在根证书，因此只需要证书颁发机构CA及其父证书即可形成证书链，通过fullchain证书可以保证浏览器对网站或服务的信任性。

    与单个数字证书相比，fullchain证书包含了完整的证书链信息，因此可以兼容各种浏览器和其他客户端。一般情况下，fullchain证书只需要在Web服务器或负载均衡器等服务上进行配置即可，不需要引入其他证书链文件，方便管理和维护。

    为什么合并了 crt 和 key 的 fullchain 证书也是可以用的？
    一般情况下，如果实体证书和证书链没有分开提供，那么可以在将证书和私钥合并为fullchain证书时，将证书和证书链一起合并。这种方式创建的fullchain证书其实包含了实体证书和证书链，所以可以用于SSL/TLS连接的加密和身份验证。

    一个证书包含一个实体证书和它的证书链，证书链又包括了由根证书（root certificate）开始的一系列证书。证书链的作用就是让客户端验证实体证书和其中间证书的信任性。如果实体证书和证书链分开提供，则需要把它们合并为fullchain证书，这样浏览器才能正确的验证证书链，进而信任该证书。

    但是，在某些情况下，服务器在发送证书时可能会省略证书链，因此，如果本地没有这些证书链，则可能会导致SSL/TLS连接无法建立，或者SSL/TLS连接不安全，容易受到中间人攻击。因此，为了保证最高的安全级别，应该使用完整的证书链，而不仅仅是实体证书和证书链的合并。

    因此在使用 haproxy 时可以采用此种方式创建 fullchain 证书。