-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issuing CA uses root CA CRL #68
Comments
I think this is correct. To find out if the current certificate (LAB Issuing ACME CA) has been revoked, we need to check with the certificate issuer, being the LAB Root CA. |
@hakwerk That makes sense, I forgot that the issuing CA would have it's CRL be the root CA. As a side note, how could LabCA handle the root CA CRL if the changes in #53 (option 1 - root CA upload) were implemented? I would think the user could have an option to upload the root CA CRL into LabCA to be served (manual process). |
@hakwerk It looks like a test leaf certificate has a nonexistent URL for the Issuing CA CRL. user@acme:~$ sudo certbot certonly --manual --preferred-challenge dns --domain testdomain.lab.local --server https://acme.lab.local/directory --register-unsafely-without-email
user@acme:~$ sudo openssl x509 -in /etc/letsencrypt/live/testdomain.lab.local/cert.pem -text | grep crl
URI:http://acme.lab.local/crl/40095325498633400.crl
user@acme:~$ curl http://acme.lab.local/crl/40095325498633400.crl
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
root@acme:~# docker exec -it 6288d35a7f2b bash
root@6288d35a7f2b:/labca# ls -l /var/www/html/crl
total 12
-rw-r--r-- 1 root root 361 Feb 18 07:42 40095325498633401-1676706131489947433-0.crl
-rw-r--r-- 1 root root 361 Feb 19 01:02 40095325498633401-1676768520000471541-0.crl
lrwxrwxrwx 1 root root 43 Feb 19 01:02 40095325498633401.crl -> 40095325498633401-1676768520000471541-0.crl
-rw-r--r-- 1 root root 983 Feb 18 07:39 root-ca.crl The Issuing CA CRL also does not appear to be updating the 01 CRL. user@acme:~$ sudo certbot revoke --cert-path /etc/letsencrypt/live/testdomain.lab.local/cert.pem --server https://acme.lab.local/directory --register-unsafely-without-email
user@acme:~$ wget http://acme.lab.local/crl/40095325498633401.crl
user@acme:~$ openssl crl -inform DER -text -noout -in 40095325498633401.crl
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: ecdsa-with-SHA384
Issuer: C = US, O = LAB, CN = LAB Intermediate ACME CA
Last Update: Feb 19 01:02:00 2023 GMT
Next Update: Feb 23 01:01:59 2023 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:EC:6E:39:FA:D8:91:15:B7:AC:84:32:3F:E6:D1:2D:E2:EC:F3:5F:D7
X509v3 CRL Number:
1676768520000471541
X509v3 Issuing Distribution Point: critical
Full Name:
URI:http://acme.lab.local/crl/40095325498633401.crl
Only User Certificates
No Revoked Certificates. |
The CRLs are generated by the Let's Encrypt boulder engine on regular intervals, not on demand after a cert is revoked. Currently I have set this in LabCA to every 24 hours. You can change this with the You can also trigger generating the CRL on demand with this command:
I've not been able to reproduce that 00/01 issue in the CRL name. It is also very unexpected to be off by one as the value is based on the SHA1 hash of the issuer certificate subject.
That is just one of several issues why #53 is not easy to implement. It is not just a GUI change but also affects several other processes in the system. I don't expect to implement #53 anytime soon. |
I see that the issuing CA CRL is listed at /certs/index.html, but the issuing CA certificate is configured to only list the root CA CRL.
Image 1
Image 2
The text was updated successfully, but these errors were encountered: