[Swan] Certificate/ID validation requirements

Nels Lindquist nlindq at maei.ca
Fri Sep 1 21:52:56 EEST 2023


The internal CA certificate we use for signing client certificates is 
expiring soon, and I'm trying to mitigate the workload of replacing 
every issued client certificate all at once.

I've reissued the CA certificate using the same private key, in the hope 
that it could be installed in the NSS certificate store and be trusted 
for previously issued client certificates which won't themselves expire 
for some time to come.

I tested this scenario using a dummy CA I created with a very short 
validity period on a host that had been rolled back in time a month. I 
used that CA to sign a server certificate and a client certificate, and 
used them in a test configuration where the signing CA had expired, but 
the client and server certificates had not. As expected, the 
certificates were not trusted.

I then reissued the dummy CA certificate with a current validity period, 
and installed it on both ends. I was eventually able to get the 
connection to work successfully, though I had to make sure the Subject 
was identical for both the expired and valid CA certificates, and 
removing the expired certificate from both client & server stores.

My test LibreSWAN endpoint is an older version than production. When I 
attempted to do the same thing for our production server, I'm unable to 
get LibreSWAN to trust the presented client certificate.

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.

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?


-- 
Nels Lindquist
nlindq at maei.ca


More information about the Swan mailing list