Problems with multiple CAs for OpenVPN in certificate manager
-
hi,
I'm currently trying to trace a problem when i have multiple (self signed)
CAs in the certificate manager for diffreren OpenVPN server instances.The symptom is the following:
I have multiple (currently 7) independent self-signed CAs in the
certificate manager, used for different OpenVPN services.
They were all created independently (using EasyRSA) and the imported
into pfSense.
Now, for some reason pfSense thinks that all certificates, including
all other CA certificates, are signed by the last CA imported
(it's always the last one imported, no matter which order).
Now, i noticed this before, but it was just a minor userinterface
issue up until and including v2.3.2_1, but with 2.3.3 this means
that some of my vpns now no longer work, as because of commit
eafd9cfb5e68b1d466f7627fc729078e21a23f1a, it now puts all of
the "certificate chain" into the ca certificates for the OpenVPN
service, which leads to validation errors, because it is not a chain
in reality.has anybody else seen this behaviour and/or is it a user error on my part?
(i have not yet stepped through the certificate manager code as i so far was looking in
the wrong place because i thought i made some error in upgrading or
decoding the certificates).any hints would be appreciated.
regards,
albert -
same problem!
-
Did you make all of those with the exact same subject? If they are all (nearly) identical it may not be able to distinguish them enough to tell who made what. It tries to locate the appropriate signing CA but if they all look alike it may not separate them properly.
-
well, country, province, city org and email are identical
(most of these CAs where created well before we started using pfsense,
all of them where created using easy rsa)so yes, if pfsense tries to look at the subject to find out if they are related this could indeed
be the reason.while using the same email address might not have been ideal, i don't think it's possible to change it afterwards, so i'm stuck with it…
regards,
albert dengg