Bug #3470

IPSec VPN not recognizing alternative IP name

Added by B. Derman over 6 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


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 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).


#1 Updated by Doktor Notor about 6 years ago

Duplicate of Bug #3347, SubjectAltNames are completely broken.

#2 Updated by B. Derman about 6 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.

#3 Updated by Doktor Notor about 6 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.

#4 Updated by B. Derman about 6 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 (

#5 Updated by Chris Buechler almost 5 years ago

  • Status changed from New to Resolved

this was all fixed some time ago.

Also available in: Atom PDF