标签: crl

最近发现的 Heartbleed 漏洞促使证书颁发机构重新颁发证书。

我有两个证书是在发现 heartbleed 漏洞之前生成的。在 SSL 颁发者告诉我重新生成证书后，我用新证书更新了我的服务器/域。

如果我的理解是正确的，那么旧证书应该已被 CA 吊销，并且应该已将其添加到 CRL（证书吊销列表）或 OCSP 数据库（在线证书状态协议）中，否则技术上可能有人执行“中间人攻击”，通过从受损证书中获取的信息重新生成证书。

有没有办法检查我的旧证书是否已通过 CRL 和 OCSP。如果他们还没有，有没有办法让他们包括在内？

更新：情况是我已经替换了我的证书，我所拥有的只是旧证书的 .crt 文件，因此使用 url 进行检查是不可能的。

我正在寻找主 CRL 列表。我发现的最接近的是 Chromium 项目的CRLSet。我使用crlset-tools来获取 crlset ( crlset fetch > crl-set) 然后转储序列号 ( crlset dump crl-set) 所以我看到了这样的东西：

f24196ae94078667348f02e8e37458a3a6e6aad1e0b0dc610118cce721427bfc
  03fb3b4d35074e
  03fbf94a0e6c39
  04097214d6c97c
  0442c6b3face55
  ....

我希望能够将包含所有坏序列的主列表的 CRL 文件传递​​给 openssl 或 curl（使用 openssl）。例如，不仅仅是传入 verisign 的 crl，我希望传入所有内容。我认为我可以使用 crlset 来做到这一点，但我认为格式不兼容。我试过了，openssl crl -inform DER -text -in crl-set但它说：

unable to load CRL
5532:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:
1319:
5532:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:ta
sn_dec.c:381:Type=X509_CRL

如果有人对如何做我所说的有任何想法或任何有创意的方法来做到这一点，请告诉我。谢谢

我有大约 30 个 Windows 2008 R2 服务器作为域的成员，并且正在尝试正确配置证书部分，以便远程桌面访问这些服务器。

问题是需要连接到这些服务器的客户端不在域中。客户端与所有域计算机位于同一内部网络上。

到目前为止，我已经完成了以下工作：

1. 创建了 CA
2. 为远程桌面身份验证配置证书模板
3. 配置默认 GPO 以启用自动注册并让远程桌面服务器从 RDP 证书模板注册证书
4. 将 CA 根证书安装到非域客户端上的本地计算机受信任证书存储中

这似乎有效，因为每个服务器都经历了自动注册过程。

问题是，当我与 RDP 客户端连接时，我收到一个证书警告，说明：

A revocation check could not be performed for the certificate

查看证书详细信息，我可以看到它是机器的正确证书，并且已由我安装并信任的 CA 根签名。在CRL Distribution Points对证书状态条目：

URL=ldap:///CN=domain-ad-CA,CN=host,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=example,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint (ldap:///CN=domain-ad-CA,CN=ad,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=thomsonreuters,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint)

根 CA 证书没有列出 CRL 位置。

猜测是，客户端尝试联系 LDAP url 并失败，但不清楚为什么会这样。如何让客户端执行吊销检查？

如何在我的域控制器中查看内存中 OCSP 缓存到 CRL 缓存的大小？

换句话说，大多数使用 CryptoAPI 的 Windows 进程都具有与该应用程序相关的每个 CRL 和 OCSP 的内存缓存。这很重要，因为客户端内存使用和网络 IO 请求数量之间存在巨大的性能权衡。

在我的情况下，CRL“客户端”是验证 WCF 证书身份验证的服务器

我怀疑构建 CRL 缓存的过程可能会导致某些应用程序出现延迟。

我们有几个 .NET 应用程序，它们偶尔会在没有 CPU 或磁盘访问的情况下“运行缓慢”。我怀疑他们在尝试验证证书时挂断了身份验证，因为超时几乎是 20 秒。

根据这篇 MSFT 文章

大多数应用程序没有指定 CryptoAPI 使用累积超时。如果未启用累积超时选项，CryptoAPI 将使用 CryptoAPI 默认设置，即每个 URL 的超时时间为 15 秒。如果应用程序指定了累积超时选项，那么 CryptoAPI 将使用默认设置 20 秒作为累积超时。第一个 URL 接收的最大超时时间为 10 秒。每个后续 URL 超时是累积超时值中剩余余额的一半。

由于这是一项服务，我如何检测和记录我拥有源代码的应用程序以及第 3 方的 CryptoAPI 挂起

情况是这样 - 有一个透明的 nginx 代理可以处理 SSL 证书，并且在我们决定添加撤销列表管理之前做得很好，这是出于安全原因所必需的。这是“ssl_crl”行发挥作用并搞砸一切的时候。

server {
    listen  80;
    rewrite ^ https://$host$request_uri permanent;
}


server {
    listen 443 ssl;
    server_name example.com;
    ssl on;
    ssl_certificate /home/netadmin/keys/tid.crt;
    ssl_certificate_key /home/netadmin/keys/tid.key;
    ssl_session_cache shared:SSL:10m;
    ssl_client_certificate /home/netadmin/keys/personchain.pem;
    ssl_crl /home/netadmin/keys/personlist.crl;
    ssl_verify_client on;
    ssl_verify_depth 2;
    error_log /var/log/nginx/debug.log debug;

    location / {
            proxy_pass      http://111.111.111.111:80;
    }

每当用户尝试使用 SSL 进行身份验证时，服务器总是会给出“400 Bad Request”错误。请注意，完全相似（因为语法不同）的配置在 Apache 中完美运行。现在证书是完美无缺的，这已经被多次证明了，这里是验证检查，例如

openssl crl -CAfile personchain.pem -inform PEM -in personlist.crl -lastupdate -nextupdate -noout
verify OK
lastUpdate=Apr 22 14:59:18 2013 GMT 
nextUpdate=Apr 29 14:59:18 2013 GMT 

CRL 链接正常工作，没有任何问题，这是错误日志的一部分。 …

我有一个自定义的 easyrsa 设置，带有一个根和三个由根签名的 CA。（三个不同的子 cas 取决于用户类型），如下所示：

RootCA
  +----- AdminUserCA
  +----- EmployeeCA
  +----- ClientCA

我使用以下配置进行身份验证：

server {
  listen               127.0.0.1:443;
  server_name          www.acme.corp;
  ssl                  on;
  ssl_certificate      /data/src/easy-rsa/bundles/www.acme.corp_bundle.crt;
  ssl_certificate_key  /data/src/easy-rsa/whfWebCA/pki/private/www.acme.corp.key;
  add_header           Strict-Transport-Security "max-age=315360000; includeSubdomains";
  ssl_protocols        SSLv3 TLSv1;
  ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA;
  ssl_prefer_server_ciphers on;
  ssl_verify_client optional;
  ssl_client_certificate /data/src/easy-rsa/bundles/client_auth_ca_chain.crt;
  ssl_verify_depth 2;
  ssl_crl /data/src/easy-rsa/bundles/crls/all.pem;

  ...
}

问题在于 CRL 检查。CRL 由颁发 CA 签名，因此它们不能像中间证书 + 根证书一样附加在一起。

因此，用户的证书将由给定的中间 CA 根据其用户类型颁发。问题是我真的需要检查四个 CRL 列表才能有效。nginxssl_crl只支持单个文件。

所以我的问题是：是否可以让 nginx 在此设置中正确检查客户端证书吊销，而无需在我的应用程序中进行检查？

我有一系列证书：MYROOTCERT -> MYCHILDCERT。MYCHILDCERT 证书具有 CRL 分发点扩展：

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://pacem/mychildcert.crl

问题是我无法连接此证书，当我使用 certutil -verify 命令检查它时，我收到吊销服务器脱机错误：

C:\Users\Administrator>certutil -verify -urlfetch C:\Share\mycerts\MYCHILDCERT.c
er
Issuer:
    CN=MYROOTCERT
Subject:
    CN=MYCHILDCERT
Cert Serial Number: 0af7c4fb38ad0bd258fde6356117896519

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

CertContext[0][0]: dwInfoStatus=2 dwErrorStatus=1000040
  Issuer: CN=MYROOTCERT
  NotBefore: 1/1/2000 …

我无法生成 CRL。我可能在配置文件中遗漏了一些东西。我得到的错误是“加载 crl 编号时出现 openssl 错误”。CRL 配置部分：

 [ CA_default ]
# Directory and file locations.
dir               = box/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand
# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/RcCA.crl
crl_extensions    = crl_ext
default_crl_days  = 30

我使用的命令：

openssl ca -config full-path-to-openssl.cnf  -gencrl -out full-path-to-RcCA.crl

其中 rcCA 是 crl 文件。文件结构：
根CA

• 证书
• 克林
• 企业社会责任
• 中间的
• 新证书
• 效果图

• 私人的

• 连续剧

• openssl.cnf
• 索引.txt
• 编号

底部三个是文件，上面是文件夹。
我找到的答案指向缺少索引文件。但它存在于我的机器上。我不知道我是否把它放在正确的位置。 …

我们的 aws 设置中有一个 OpenVPN，它是由客户端设置的，现在他们无法连接到开放 VPN，说“crl 已过期”。我们正在尝试重新生成 crl，但要做到这一点，我们需要转到 easy-rsa 文件夹，在那里我需要运行以下命令：

• cd 路径/到/easy-rsa/目录
• 这里需要运行以下命令

./easy-rsa crl-gen

• 但这里的问题是 easy-rsa 目录中的 easy-rsa 脚本文件丢失，没有它我们将无法生成 crl。

2019 年 8 月 27 日星期二 10:25:17 122.166.3.167:18363 验证错误：深度=0，错误=CRL 已过期：C=US、ST=CA、L=旧金山、O=Fort-Funston、OU=MyOrganizationalUnit、CN =pkoparde，名称=EasyRSA，电子邮件地址=me@myhost.mydomain
2019 年 8 月 27 日星期二 10:25:17 122.166.3.167:18363 OpenSSL: 错误:14089086:SSL 例程:ssl3_get_client_certificate:证书验证失败
2019 年 8 月 27 日星期二 10:25:17 122.166.3.167:18363 TLS_ERROR：BIO 读取 tls_read_plaintext 错误
2019 年 8 月 27 日星期二 10:25:17 122.166.3.167:18363 TLS 错误：TLS 对象 -> 传入明文读取错误
2019 年 8 月 27 日星期二 10:25:17 122.166.3.167:18363 TLS 错误：TLS 握手失败
2019 年 …