[Swan] Certificate/ID validation requirements

[Nels Lindquist]

On 2023-09-01 3:40 PM, Paul Wouters wrote:

> On Sep 1, 2023, at 14:53, Nels Lindquist <nlindq at maei.ca> wrote:
>>
>> I noted in a previous email thread that newer versions do more stringent certificate validating; the endpoint which is failing is version 4.7. Clients are Windows, btw.
> 
> Windows checks its own certificate chain validity and if not valid won’t use the certificate. Apple products just use their end certificate and as long as they can validate the server cert, they don’t care about the client cert not having a valid path.

Yes; I confirmed that an otherwise valid certificate with an expired CA 
in the Trusted Root won't even be presented by Windows.

>> Is what I'm trying to do even possible with later versions? What attributes of the CA certificate are being used to validate the chain?
> 
> Not with windows, they need a new valid PKCS12 certificate bundle.

I thought that too, but it turns out not to be the case!

I was able to "heal" the chain for Windows by importing a new CA 
certificate PEM file (requested and signed from the same private key, 
with the identical Subject) into the "Trusted Root Certification 
Authorities" section of the Computer certificate store. The client 
certificate (in the Personal section) then changed from invalid to 
valid, and the certification path now shows the "new" version of the CA 
cert as the signer. I didn't even need to delete the expired CA cert for 
this to work.

As can be demonstrated in the libreswan logs, Windows will then happily 
present the client certificate when negotiating a connection.

On the libreswan side, deleting the expired CA and importing the new one 
(leaving the still valid leftcert untouched) into the NSS db allows the 
connection to be established--on the older version (3.32) in my test 
environment, at least.

I need to try using my "test cert" bundle on a newer version to 
determine whether my failed attempt to make this work in the production 
environment was due to more stringent checking in a newer version of 
libreswan, or some subtle difference in the way the reissued production 
CA was generated, or something else. I was assuming a version 
difference, but in retrospect I need to prove that's actually the case.

As the production CA hasn't actually expired yet, this can wait until 
after the weekend.

> Note for the server you can use a LetsEncrypt certificate and it will validate for the clients. You don’t have to have to same CA for both ends.

Good to know!

-- 
Nels Lindquist
nlindq at maei.ca