由于根证书过期，gitlab-runner 无法克隆
[英]gitlab-runner cannot clone due to expired root certificate
问题描述
I have this error while cloning on gitlab ci:
在 gitlab ci 上克隆时出现此错误：
unable to access 'https://gitlab-ci-token:[secure]@git.mydomain.com/mydomain/api.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none.
My Root CA has expired today the 30th and thus must have been removed from my keychain.我的根 CA 已于今天 30 日到期，因此必须从我的钥匙串中删除。
I have upgraded my certificates (debian) and all seems fines except this error does not go away in my dockerized gitlab-runner .我已经升级了我的证书（debian），除了这个错误在我的 dockerized gitlab-runner中没有 go 之外，一切似乎都很好。
How can I fix it?我该如何解决？
2 个解决方案
解决方案1
1 已采纳 2020-05-30 19:03:43
This is a problem on the server side, and it needs to be fixed by replacing the chain of CA certificates.这是服务器端的问题，需要通过更换CA证书链来解决。
Because Sectigo knew that this root certificate would expire soon, several years ago, they created a new root certificate and registered it with all the major browser vendors and OS manufacturers.因为 Sectigo 知道这个根证书很快就会过期，所以几年前，他们创建了一个新的根证书，并在所有主要的浏览器供应商和操作系统制造商处注册。 However, because many older systems don't upgrade their certificates, this new root CA was signed by an older CA, a process called cross-signing .但是，由于许多旧系统不升级其证书，这个新的根 CA 由旧 CA 签名，这个过程称为交叉签名。 This allows people to use the new root for issuing certificates yet remain compatible with older systems.这允许人们使用新的根来颁发证书，同时保持与旧系统的兼容性。
Any systems on the Internet today can no longer handle the legacy root because it's now expired, so there's no benefit to using it anymore.今天互联网上的任何系统都不能再处理遗留根，因为它现在已经过期，所以不再使用它没有任何好处。
Some TLS libraries can figure out that a certificate chains to a trusted root and ignore the extra, expired root certificates, but some cannot.一些 TLS 库可以确定证书链接到受信任的根并忽略额外的过期根证书，但有些则不能。 As a result, the fact that you have the old AddTrust External Root CA certificate in your certificate chain can break some of those TLS libraries, which is what's happening here.因此，您在证书链中拥有旧的 AddTrust 外部根 CA 证书这一事实可能会破坏其中一些 TLS 库，这就是这里发生的情况。
Sectigo has documentation on this issue . Sectigo 有关于这个问题的文档。 You want to remove the AddTrust CA certificate and make sure that the UserTrust or COMODO root that you're using is self-signed.您想要删除 AddTrust CA 证书并确保您使用的 UserTrust 或 COMODO 根是自签名的。 If you're using a Debian or Ubuntu system, you may be able to find the appropriate root certificate in /etc/ssl/certs .如果您使用的是 Debian 或 Ubuntu 系统，您可以在/etc/ssl/certs中找到相应的根证书。
Even better, you can just remove the root certificate altogether and only include intermediates, since the root certificate isn't actually needed when creating the TLS connection, since the client must already have it.更好的是，您可以完全删除根证书并仅包含中间证书，因为在创建 TLS 连接时实际上不需要根证书，因为客户端必须已经拥有它。
解决方案2
1 2021-10-01 07:56:48
In debian 9, I resolved issue by removing below certificate.在 debian 9 中，我通过删除以下证书解决了问题。
sudo rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
sudo update-ca-certificates
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.