Skip to main content
school-admin
Visitor III
May 11, 2026
Solved

Using multiple wildcard certificates with "Protecting SSL server"

  • May 11, 2026
  • 1 reply
  • 69 views

The documentation states you can define multiple certificates in an SSL profile in replace mode and it will compare the server name identification (SNI) and the common name (CN) with the certificate list in the SSL profile, and use the matched certificate as a replacement. If there is no matched server certificate in the list, then the first server certificate in the list is used as a replacement.

However, this does not seem to work if you are using wildcard certificates. I have an SSL profile that has multiple separate wildcard certificates defined in the profile that is used to protect a highly available reverse proxy for several domains and subdomains.

e.g. SSL Profile in replace mode has separate wildcard certificates for *.abc.net, *.abc.com, *.io.abc.com, *.abc.org, *.bbc.com, *.bbc.org. 

If a request comes in with an SNI of www.abc.com it will instead return the first certificate *.abc.net as the exact CN name matching does not match the wildcard.

Has anyone else experienced this issue or know of a way to make it work? The only way we have found is to create a single certificate that has all the wildcards in it, but this can also cause info disclosure of the hosts on the IP and if they are for different organisations it can be difficult getting all the wildcards in the one cert.

Thanks.

Best answer by Sheikh



 

The SSL profile’s certificate selection is likely doing exact string matching instead of proper wildcard matching.

So when:

  • SNI = www.abc.com
  • Cert = *.abc.com

The system does not treat it as a match and falls back to the first certificate in the profile (e.g.*.abc.net).

Key points:

  • Many ADC/reverse proxy platforms compare SNI/CN/SAN literally.
  • Wildcard certificates often fail unless the platform explicitly supports RFC-compliant wildcard matching.
  • Some platforms only check SANs, not CNs.
  • Certificate order matters because unmatched requests use the first cert.

Workarounds:

1 reply

Sheikh
Staff
SheikhAnswer
Staff
May 11, 2026



 

The SSL profile’s certificate selection is likely doing exact string matching instead of proper wildcard matching.

So when:

  • SNI = www.abc.com
  • Cert = *.abc.com

The system does not treat it as a match and falls back to the first certificate in the profile (e.g.*.abc.net).

Key points:

  • Many ADC/reverse proxy platforms compare SNI/CN/SAN literally.
  • Wildcard certificates often fail unless the platform explicitly supports RFC-compliant wildcard matching.
  • Some platforms only check SANs, not CNs.
  • Certificate order matters because unmatched requests use the first cert.

Workarounds:

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.
AEK
SuperUser
SuperUser
May 11, 2026

Additionally to Sheikh’s explanation, If this is production then I recommend to use FortiWeb if it is possible. This will avoid such limitation and so many other headaches.

AEK