Re: OpenSSL doesn't show all the requested extensions for a CSR
Viktor Dukhovni <[email protected]> Wed, 6 Aug 2025 16:58:55 +1000
| Newsgroups | gmane.comp.encryption.openssl.user |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Aug 05, 2025 at 07:47:50PM -0500, Thomas Anderson wrote:
> Here's a CSR I kinda hacked together:
>
> -----BEGIN NEW CERTIFICATE REQUEST-----
> MIIBADCBqAIBADATMREwDwYDVQQKDAh3aGF0ZXZlcjBZMBMGByqGSM49AgEGCCqG
> SM49AwEHA0IABInX+1ey1zZ9zM4z4rxTJVxdtMpBNlrwK9mae1DaPkGqvtXCr/ER
> AJpPDgWJcT2j9W5EjvrMtUxe5yujJw210DSgMzAxBgkqhkiG9w0BCQ4xJDANMAsG
> A1UdDwQEAwIBhjATMBEGA1UdDgQKBAhkZWFkYmVlZjAKBggqhkjOPQQDAgNHADBE
> AiAORfemho2gtZudBD8BGUvKBeQOVeg4fzkJTYTkqk4cKwIgGhdlouh2dVGbCa4t
> Iq3EaI+b4OMe2uEb3mmftiefvok=
> -----END NEW CERTIFICATE REQUEST-----
The above CSR is not consistent with section 5.4.2 of RFC2985 (PKCS#9).
https://datatracker.ietf.org/doc/html/rfc2985#page-17
which defines the "extensionRequest" attribute to consist (as a set of
values) of a single element which is a sequence of extensions.
> Here's the output of openssl asn1parse -i -in test.pem :
>
> 0:d=0 hl=4 l= 256 cons: SEQUENCE
> 4:d=1 hl=3 l= 168 cons: SEQUENCE
> 7:d=2 hl=2 l= 1 prim: INTEGER :00
> 10:d=2 hl=2 l= 19 cons: SEQUENCE
> 12:d=3 hl=2 l= 17 cons: SET
> 14:d=4 hl=2 l= 15 cons: SEQUENCE
> 16:d=5 hl=2 l= 3 prim: OBJECT :organizationName
> 21:d=5 hl=2 l= 8 prim: UTF8STRING :whatever
> 31:d=2 hl=2 l= 89 cons: SEQUENCE
> 33:d=3 hl=2 l= 19 cons: SEQUENCE
> 35:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
> 44:d=4 hl=2 l= 8 prim: OBJECT :prime256v1
> 54:d=3 hl=2 l= 66 prim: BIT STRING
> 122:d=2 hl=2 l= 51 cons: cont [ 0 ]
> 124:d=3 hl=2 l= 49 cons: SEQUENCE
> 126:d=4 hl=2 l= 9 prim: OBJECT :Extension Request
> 137:d=4 hl=2 l= 36 cons: SET
> 139:d=5 hl=2 l= 13 cons: SEQUENCE
> 141:d=6 hl=2 l= 11 cons: SEQUENCE
> 143:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
> 148:d=7 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020186
> 154:d=5 hl=2 l= 19 cons: SEQUENCE
> 156:d=6 hl=2 l= 17 cons: SEQUENCE
> 158:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
> 163:d=7 hl=2 l= 10 prim: OCTET STRING [HEX DUMP]:04086465616462656566
> 175:d=1 hl=2 l= 10 cons: SEQUENCE
> 177:d=2 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
> 187:d=1 hl=2 l= 71 prim: BIT STRING
While what you have above is a set of two 1-element sequences. Sadly, a
set of two 1-element sequences is not the same as a set containing a
single 2-element sequence.
{ [a], [b] } != { [[a], [b]] }
> So it's showing "X509v3 Subject Key Identifier" and "X509v3 Key Usage".
Yes, but not in the format specified in PKCS#9.
> To understand this let's consider this CSR:
>
> -----BEGIN NEW CERTIFICATE REQUEST-----
> MIH/MIGmAgEAMBMxETAPBgNVBAoMCHdoYXRldmVyMFkwEwYHKoZIzj0CAQYIKoZI
> zj0DAQcDQgAEXj0aPYgbLFMlCwD89DQCjIBG+axx6uiq6t4ZgUOK+9piM3+3aScq
> CKEDRDY8dmFYetIxS8xW3t513N+1BTwWSqAxMC8GCSqGSIb3DQEJDjEiMCAwCwYD
> VR0PBAQDAgGGMBEGA1UdDgQKBAhkZWFkYmVlZjAKBggqhkjOPQQDAgNIADBFAiEA
> uutZz9KNjvXw0fqa3NOIZRHQP4rS+tLrLxfmb8lgKi4CIA/m3oLwSxNDom0q406p
> FUp0Wt/MkYMrHiKG2InRK9V+
> -----END NEW CERTIFICATE REQUEST-----
This CSR is consistent with the specification.
> Here's the openssl asn1parse for this new CSR:
>
> 0:d=0 hl=3 l= 255 cons: SEQUENCE
> 3:d=1 hl=3 l= 166 cons: SEQUENCE
> 6:d=2 hl=2 l= 1 prim: INTEGER :00
> 9:d=2 hl=2 l= 19 cons: SEQUENCE
> 11:d=3 hl=2 l= 17 cons: SET
> 13:d=4 hl=2 l= 15 cons: SEQUENCE
> 15:d=5 hl=2 l= 3 prim: OBJECT :organizationName
> 20:d=5 hl=2 l= 8 prim: UTF8STRING :whatever
> 30:d=2 hl=2 l= 89 cons: SEQUENCE
> 32:d=3 hl=2 l= 19 cons: SEQUENCE
> 34:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
> 43:d=4 hl=2 l= 8 prim: OBJECT :prime256v1
> 53:d=3 hl=2 l= 66 prim: BIT STRING
> 121:d=2 hl=2 l= 49 cons: cont [ 0 ]
> 123:d=3 hl=2 l= 47 cons: SEQUENCE
> 125:d=4 hl=2 l= 9 prim: OBJECT :Extension Request
> 136:d=4 hl=2 l= 34 cons: SET
> 138:d=5 hl=2 l= 32 cons: SEQUENCE
> 140:d=6 hl=2 l= 11 cons: SEQUENCE
> 142:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
> 147:d=7 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:03020186
> 153:d=6 hl=2 l= 17 cons: SEQUENCE
> 155:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
> 160:d=7 hl=2 l= 10 prim: OCTET STRING [HEX DUMP]:04086465616462656566
> 172:d=1 hl=2 l= 10 cons: SEQUENCE
> 174:d=2 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
> 184:d=1 hl=2 l= 72 prim: BIT STRING
This has a set with a single element which is a 2-element sequence
in conformance with PKCS#9.
> My question is... *should* the first CSR be showing both extension
> requests or shouldn't it be?
It is not a well-formed CSR. It would ideally be rejected by the CSR
parser, because the multiplicitly of the requested extensions set is
incorrect. Unfortunately, it excess requested extensions elements
appear to be silently ignored. If there isn't yet an open issue on
Github covering this, please open one.
> I mean, right now it isn't, but how *ought* a CSR like the first one
> behave?
It isn't a valid CSR, so its behaviour is undefined, but rejection is
likely the right outcome.
--
Viktor. 🇺🇦 Слава Україні!
--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aJL9L1w8dJ1pW8xh%40chardros.imrryr.org.