Forum Discussion

F5beginner_3849's avatar
F5beginner_3849
Icon for Nimbostratus rankNimbostratus
Apr 16, 2019

Bad certificate assigned to Host

Hello,

 

I have a virtual server, which have more certificates. I´m using SNI to differentiate URL hosts.

 

Let´s say I have two domains: exmaple.com and test.com and Certificates have defined SNIs,this working properly. Problem is when I use www before host, so when I use I receive bad certificate(default).

 

How to solve this problem?

 

EDIT: I have created http profile and make redirection rule from to https://example.sk, before this issue I had this tcl command: tcl:https://[getfield [HTTP::host] : 1][HTTP::uri], is there any way to edit it to delete www from URL ?

 

Thank you

 

4 Replies

  • You will need to define and in your SNI as these are different hosts to test.com and example.com. Otherwise, consider wildcard certificates for *.test.com and *.example.com

     

    If you do not have a working certificate for www.* you will not be able to do a redirect from https://www.example.sk to https://example.sk without causing a certificate error. This is because SSL/TLS is terminated before HTTP

     

  • Your certificate SNIs need to match the FQDN so if your certificate allows for

    test.com
    and
    example.com
    then it will not allow
    something.test.com
    or
    mail.example.com
    .

    Best option is to update the certificate to include all the FQDNs you need client to access your service.

  • If you have wildcard certificate for your domain, use that. Certificate will be *.example.com, make it default and in sni use *.example. It will work fine without error.

     

  • Regarding you second part if using an iRule you could do something like the following to update the host name:

    when HTTP_REQUEST {
        if {!([HTTP::host] starts_with "example.com") and !([HTTP::host] starts_with "test.com")} {
            HTTP::redirect "https://[join [lreplace [split [getfield [HTTP::host] : 1] "."] 0 0] "."][HTTP::uri]"
        }
    }
    

    This will only work on a HTTP connection, on HTTPS the client would still get an error before the redirect occurs.