Remove keyUsage and extKeyUsage from x509 certificate using template #2221
Replies: 1 comment 1 reply
-
|
Hi @ZeroClover, when configuring an ACME provisioner with your template, and issuing a certificate from that provisioner, I get the following: $ step ca certificate localhost l.crt l.key --provisioner acme
✔ Provisioner: acme (ACME)
Using Standalone Mode HTTP challenge to validate localhost . done!
Waiting for Order to be 'ready' for finalization .. done!
Finalizing Order .. done!
✔ Certificate: l.crt
✔ Private Key: l.key
$ step certificate inspect l.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 167039295925450617407140022603339243153 (0x7daa99230f48b396d7b32002962b9e91)
Signature Algorithm: ECDSA-SHA256
Issuer: O=Test,CN=Test Intermediate CA
Validity
Not Before: Mar 24 11:20:54 2025 UTC
Not After : Mar 25 11:21:54 2025 UTC
Subject: CN=localhost
Subject Public Key Info:
Public Key Algorithm: ECDSA
Public-Key: (256 bit)
X:
a7:72:40:06:52:0c:74:63:b7:8f:b0:7a:f4:04:2e:
f9:49:ee:9c:6a:9d:fa:b8:00:bb:bc:bb:e1:8f:29:
ce:10
Y:
28:28:e4:b5:ca:5d:57:7a:0b:f4:84:2a:26:e0:40:
da:0b:66:66:bc:35:bf:8b:84:ea:f3:75:19:8b:ad:
66:4b
Curve: P-256
X509v3 extensions:
X509v3 Extended Key Usage:
Server Authentication
X509v3 Subject Key Identifier:
C2:5A:B9:2D:88:67:C5:C2:97:2B:6F:F4:D1:22:99:B4:31:05:AB:6F
X509v3 Authority Key Identifier:
keyid:4E:84:57:DD:F9:E0:6D:22:F6:FC:72:BA:C6:7A:ED:35:4C:31:B3:D0
X509v3 Subject Alternative Name:
DNS:localhost
X509v3 CRL Distribution Points:
Full Name:
URI:http://domain.tld/1.0/crl
X509v3 Step Provisioner:
Type: ACME
Name: acme
Signature Algorithm: ECDSA-SHA256
30:45:02:20:75:3d:50:0d:a5:81:ab:e6:a9:f2:e7:16:1c:66:
35:ac:b1:0f:b4:2f:2c:d0:c0:bd:63:02:4a:98:46:63:dc:87:
02:21:00:fd:1f:a7:01:3a:9e:ba:93:56:a6:29:39:fb:9f:c6:
53:0a:16:a5:51:3d:e3:53:22:69:91:47:69:f5:ad:5a:7eThis seems to be what you're after. If you meant the CA's own leaf certificate doesn't adhere to your template: that's currently expected behavior. The private key and corresponding certificate are created on CA startup, because the contents of this certificate (partially) depend on the CA configuration, and are dynamic (to a certain extent). Besides that, the CA will use its leaf certificate both to terminate TLS as a server certificate, as well as in outgoing TLS requests as a client certificate. We thus enforce certain properties by not making them all configurable. |
Beta Was this translation helpful? Give feedback.
-
|
I created the certificate through the JWK provisioner The issued leaf certificate contains the CRL distribution point I specified, so it's strange that the template was at least partially applied. |
Beta Was this translation helpful? Give feedback.
-
I attempted to remove keyUsage from the X509 leaf certificate through a template and restrict extKeyUsage to serverAuth only, in order to stay consistent with Let's Encrypt's latest standards and verify the compatibility of this change before LE implements it.
https://letsencrypt.org/docs/profiles/
I added the following configuration in ca.json:
And used this template:
{ "subject": {{ toJson .Subject }}, "sans": {{ toJson .SANs }}, "extKeyUsage": ["serverAuth"], "crlDistributionPoints": ["http://domain.tld/1.0/crl"] }However, this doesn't seem to work; the issued leaf certificate still contains keyUsage and extKeyUsage for clientAuth.
Beta Was this translation helpful? Give feedback.
All reactions