Multi Wildcard SSL Certificat Not Working

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: * and * I spoke to the certificate company (Digicert) and they said to go with * as the CN and * 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 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; its security certificate is from
* This may be caused by a misconfiguration or an attacker intercepting your

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 -
 Running on: Linux 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64



    	ssl-default-bind-options  ssl-min-ver  TLSv1.2
	ssl-default-bind-ciphers  ECDHE-ECDSA-AES256-GCM-SHA384:

frontend http-in-VIP12-nlbtest

	bind  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 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 ssl verify none maxconn 1024

You got bad advice from Digitcert, you need to have both * and * 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:


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