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
[email protected]
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
