Haproxy - SNI SSL offloading with Subject Alternative Names

[Dennis1984120]

Hi,

I'm using Haproxy in pfSense as front-end to my web site. This site is only reachable over https. Works like a charm and I'm publishing multiple sites now on port 80 and that works fine as well. pfSense has an option in Haproxy to use SNI to publish multiple web sites. The only problem is the ACL for certificate CommonNames.

This works fine when you have a site where the common name matches the website host header, but my website runs on https://website.com and not on https://www.website.com. This gives no problem as my PositiveSSL certificate has a subject alternative name (SAN) which allows both the website with or without 'www'.

Unfortunately, the ACL which gets created does not check for the subject alternative names and therefore this options will not work for me.

It this something to fix?

[PiBa]

Im not sure it needs fixing.. Perhaps added as a separate option.?. If you have multiple certificates www.X.tld mail.X.tld forum.X.tld all of them would likely have the alternative name X.tld, and likely only one should actually respond to that name..

In the mean time you can leave the cert acl unchecked, and define it manually as an acl.


[Dennis1984120]

@PiBa:

Im not sure it needs fixing.. Perhaps added as a separate option.?. If you have multiple certificates www.X.tld mail.X.tld forum.X.tld all of them would likely have the alternative name X.tld, and likely only one should actually respond to that name..

That is not the case, this situation only applies to domains with or without 'www'. If you buy a certificate for a subdomain, they don't give a subject alternate name at all: in these situations you need to pay extra if you want a certificate which validates multiple domains.

Also, RFC2818 states:

If a subjectAltName extension of type dNSName is present, that MUST
  be used as the identity. Otherwise, the (most specific) Common Name
  field in the Subject field of the certificate MUST be used. Although
  the use of the Common Name is existing practice, it is deprecated and
  Certification Authorities are encouraged to use the dNSName instead.

So the CN is officially deprecated, although it is still common these days.

I agree that it should be an extra option, perhaps another checkbox "Add ACL for certificate Subject Alternative Names."

In the mean time you can leave the cert acl unchecked, and define it manually as an acl.

I have read the haproxy docs once again, and saw this:

The certificates will be presented to clients who provide a valid
TLS Server Name Indication field matching one of their CN or alt subjects.

Which means that it should give the right certificate to the client anyway, because SNI support is built-in into haproxy and because pfSense does put all the certificates in a directory.

So while it is still interesting to have this feature built-in, you won't need it in most cases as support in pfSense will currently do.

[PiBa]

Adding acl's is not used for selecting the certificate thats gets send back to the client which is only influenced by SNI and haproxy itself, it is however used for selecting which backend will actually serve the request. So if your hosting multiple sites, on different webserver behind 1 public ip, the using acl's is required for that. As you probably know the used host header for the acl can only be read after the ssl-handshake already completed.

Ill check if i can add the option "Add ACL for certificate Subject Alternative Names." you mention, it seems indeed the X.tld is only added by default (by some ca's) for the www. subdomain.