Multi Wildcard SSL Certificat Not Working

Help!
1

I have been using HAProxy for many years and, to date, all of our applications have used either regular HTTP or SSL Passthrough. Now, however, our application development (AD) group is migrating their web application server environment to new VMs for ~70 applications spread over multiple front end DNS names using a mix of SSL and non-SSL. I need to direct traffic to backends based upon a combination of SSL/non-SSL, the DNS host name and the URL path. So, for the SSL applications, I need to decrypt the traffic to select the appropriate backend. For those same SSL apps, I then need to re-encrypt for transit from the load-balancer to the backend servers.

Because there are multiple host names, plus planning for the future where more host names may be added, I went with a dual wildcard certificate: *.domainA.com and *.domainB.com. I spoke to the certificate company (Digicert) and they said to go with *.domainA.com as the CN and *.domainB.com as a SAN. I created the CSR and, when I received the .crt file, I then combined it and the private key into a .pem file. The AD backend servers also have formal Digicert certs on them.

The problem is that it doesn’t seem to be working. I have a test configuration where the URL is nlbtest.domainA.com. Note that the backend server for nlbtest uses a self-signed cert. I’ve tested using Chrome, Firefox and Edge and none of them work. For example, when I use Chrome, I get the message:

This server could not prove that it is nlbtestprd.domainA.com; its security certificate is from
*.domainA.com. This may be caused by a misconfiguration or an attacker intercepting your
connection.

My question is: What am I doing wrong with this? Is this a configuration issue? Or a certificate issue, an issue with how I created the .pem file or maybe with the CSR?

The relevant test portion of the configuration is below. And my haproxy version is:

 HAProxy version 2.6.2-16a3646 2022/07/22 - https://haproxy.org/
 Running on: Linux 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64

Thanks.

Dan.

global
    	ssl-default-bind-options  ssl-min-ver  TLSv1.2
	ssl-default-bind-ciphers  ECDHE-ECDSA-AES256-GCM-SHA384:
        ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
        ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:
        ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:
        ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
        ECDHE-RSA-AES128-SHA256

frontend http-in-VIP12-nlbtest

	bind 10.14.172.39:80
	bind 10.14.172.39:443  ssl crt /etc/haproxy/ProdNLB.20220913.pem  ssl-min-ver  TLSv1.2

	mode       http

	option     http-keep-alive
	timeout    http-keep-alive  10m

	http-request add-header X-Forwarded-Proto https
	http-request add-header X-Forwarded-Port  443

	http-response add-header Strict-Transport-Security max-age=3600

	acl Host_NLBTest   hdr_beg(host) -i nlbtest

	use_backend  Cluster_NLBTEST_Prod_NoSSL  if  !{ ssl_fc }
	use_backend  Cluster_NLBTEST_Prod_SSL    if   { ssl_fc }

# http://nlbtest/...
backend Cluster_NLBTEST_Prod_NoSSL

	mode http
	option http-keep-alive
	balance roundrobin

	server  testsvr.domainA.com testsvr.domainA.com check port 80 inter 5000 fall 2 rise 3 maxconn 1024

# https://nlbtest/...
backend Cluster_NLBTEST_Prod_SSL

	mode http
	option http-keep-alive
	balance roundrobin

	server  testsvr.domainA.com testsvr.domainA.com:443 ssl verify none maxconn 1024
2

You got bad advice from Digitcert, you need to have both *.domainA.com and *.domainB.com in SAN.

CN was always ignored in the presence of SAN see RFC2818, however since a few years CN matching is completely deprecated in browsers:

3

Lukas,

Thank you. I will get the certificate reissued and try again.

Dan.