Bug #3470
closed
IPSec VPN not recognizing alternative IP name
0%
Description
Using a self-created/signed CA (created via pfSense's nice Certificate Manager), I created a server and user certificate with a common name of gateway.mydomain.com and subject alternative IP names for the 1 real WAN IP and the 4 CARP VIP WAN IPs.
When used with an OpenVPN config where the server was indicated only via the WAN IP address (a static CARP VIP and the "local" directive used to bind OpenVPN to it), the certificate worked fine but when used with an equivalent IPSec config, the error "WARNING: unable to get certificate CRL at depth:0" (and depth:1) is logged and connections fail.
Generating another set of certificates having only the applicable IP address as the common name worked around the problem (and verified that the issue was non-recognition of the alternative IP name).
Updated by Doktor Notor about 10 years ago
Duplicate of Bug #3347, SubjectAltNames are completely broken.
Updated by B. Derman about 10 years ago
#3347 claims that SANs don't work at all but, in my configuration, they do work for OpenVPN where the SAN is of type IP address. That seems to indicate that either SANs are partially working (i.e., when of type IP) or that OpenVPN is accepting a certificate it shouldn't. If it's the latter, that's an important issue.
Updated by Doktor Notor about 10 years ago
If you take the certificate and look at it via OpenSSL, you can clearly see the extensions are completely missing. If you assign the certificate to a webGUI and browse via a SAN (even an IP), you will get a mismatch warning from browser in 100% of cases. So yes, these are completely broken.
Updated by B. Derman about 10 years ago
Since OpenVPN accepts a certificate that was created with a common name that doesn't match the IP address to which OpenVPN is connecting, nor does it match the FQDN that's the common name of the certificate (but does match the IP SAN set for the certificate ... which apparently doesn't exist in the certificate), I've filed bug 3602 (https://redmine.pfsense.org/issues/3602).
Updated by Chris Buechler over 8 years ago
- Status changed from New to Resolved
this was all fixed some time ago.