Is there a reason not to include authkeyId in self signed certs?

[Jafaral]

I used strongswan's pki to generate cert chain including a self-signed root CA. When using the chain between strongswan's server/client it works fine. Recent MacOS/Windows clients are refusing to work, and MacOS thinks that my root CA is an intermediate CA. The only thing can think of is that the CA is missing the optional "authkeyId" fields compared to other root CA's I have, including self signed CAs. The authkeyId field is just a copy of the subjkeyId in those cases.

[tobiasbrunner]

The only thing can think of is that the CA is missing the optional "authkeyId" fields

Then look closer and think harder because that's not it ;-) The field is definitely optional for self-signed root certificates. RFC 5280, section 4.2.1.1 says this:

... where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted. The
signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key. (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.

[Jafaral]

Then look closer and think harder because that's not it ;-) The field is definitely optional for self-signed root certificates. RFC 5280, section 4.2.1.1 says this:

Oh I don't disagree! I already said "optional" because I had looked at that rfc already ;-). But... if I follow the instructions to create a CA chain here:

https://docs.strongswan.org/docs/5.9/pki/pkiQuickstart.html

And copied the CA to a mac, MacOS still thinks it is an intermediate CA! If I create the CA using OpenSSL and include the authkeyId, then MacOS is happy. Is it wrong to change the pki --self command to generate a cert with that field in? If you point to me the code, I Can make that change and test and report back.

Thanks!

[Jafaral]

I'm using Strongswan 6.0, which by default uses pss padding with RSA signatures. As of 2024, Apple hasn't heard yet of pss so it was failing to verify strongswan certs.

Everything worked using a new chain when generated with:

--rsa-padding pkcs1

Including Root CA certs that are now recognized correctly.

[tobiasbrunner]

Thanks for the update. I've found a lot of messages about certificates with RSASSA-PSS signatures not being supported by Apple in their community forum and elsewhere, going back at least 10 years. Many in combination with Microsoft/Windows CAs as they seem to use PSS padding by default as well. That's really unfortunate and, as usual with Apple, there is no information whether that will change anytime soon (if at all).

You mentioned Windows in your original post. I guess these clients did not actually have the same issue? (Considering a CA built with Windows will use PSS padding by default from what I've seen.)

[Jafaral]

Windows was failing because of another bit in the cert. When I generated the end entity cert for a user I used

--flag clientAuth
--flag ikeIntermediate
--flag msSmartcardLogon

These were all listed under EKU when looking at the cert properties on Windows. Windows does allow selecting which EKU to use/ignore, they have a checkbox next to each one. After dropping the msSmartcardLogon option it worked. It seems that Windows only considers smartcards in that case to lookup the private key. So, unlike other implementations, on Windows, msSmartcardLogon means it must be used with a smartcard rather than it can be used with a smartcard.

[tobiasbrunner]

As you could probably guess from the prefix ms, that's a Microsoft extension (the OID is 1.3.6.1.4.1.311.20.2.2). So other systems will most likely ignore it. Microsoft's docs about enabling smartcard logon do list it as a requirement for the client certificate, so it's possible that they then enforce that such a certificate can only be used with a smartcard.

[Jafaral]

And Apple will not be fixing the pss issue anytime soon. Hiring an engineer to fix that will cut into their already super thin profit margins. They however are happy to hire 5 engineers to convince/fool you that "it just works" 😁