Skip to content
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

Closed
tjmullicani opened this issue Feb 18, 2023 · 4 comments
Closed

Issuing CA uses root CA CRL #68

tjmullicani opened this issue Feb 18, 2023 · 4 comments

Comments

@tjmullicani
Copy link

tjmullicani commented Feb 18, 2023

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

@tjmullicani tjmullicani changed the title Issuing CA uses root CA CRL distribution Issuing CA uses root CA CRL Feb 18, 2023
@hakwerk
Copy link
Owner

hakwerk commented Feb 18, 2023

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.
In the leaf certificates the CRL of the LAB Issuing ACME CA is present because that is where we can check if a leaf certificate was revoked.

@tjmullicani
Copy link
Author

tjmullicani commented Feb 18, 2023

@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).

@tjmullicani
Copy link
Author

@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.

@hakwerk
Copy link
Owner

hakwerk commented Feb 19, 2023

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 updatePeriod setting in the /home/labca/boulder_labca/config/crl-updater.json file. You need a docker restart boulder-boulder-1 for the change to take effect.

You can also trigger generating the CRL on demand with this command:

docker exec -it boulder-boulder-1 ./bin/boulder crl-updater --config labca/config/crl-updater.json -runOnce -debug-addr :18021

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.


how could LabCA handle the root CA CRL if the changes in #53 (option 1 - root CA upload) were implemented?

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.

@hakwerk hakwerk closed this as completed Apr 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants