Forum Discussion

iamsajjad's avatar
iamsajjad
Icon for Cirrus rankCirrus
Mar 31, 2022
Solved

Problem applying 2 EC certs to a VS - NET::ERR_CERT_COMMON_NAME_INVALID

We have a virtual server that is currently configured for SSL Offloading using an L1F EC cert by Entrust. Current cert has about 240 SANs. Customer wants to add few more SANs. To manage it efficiently TLS team created a new cert with required SANs and different common name from the the first one. There is no common SAN in both certs. Client SSL Profile bound to old certificate has default SNI checked. Another client SSL profile is bound to the new EC certificate. As we try to browse addresses of second cert we see certificate error NET::ERR_CERT_COMMON_NAME_INVALID. There is only one (old) certificate applied to the virtual server as we see . I have tried building a bundle too using the old and new certificate. No luck either. Any suggestion/pointer will be appreciated. 

  •  

    About common name field, it was suggestion. According to link below in 14.1.4 version it isn't necessary. F5 matches SNI with SAN list.

    Unfortunately, I don't have any more ideas how to solve it. Looks like a bug and reason to open a support case. 

    https://support.f5.com/csp/article/K13452

    "For Server Name, enter the name of the HTTPS site.

    Note: Beginning in BIG-IP 11.6.0, if you leave Server Name blank, the BIG-IP system reads the Subject Alternative Name (SAN) from the certificate. For versions prior to BIG-IP 11.6.0, if you leave Server Name blank, the BIG-IP system reads the Common Name (CN) from the certificate. Additionally, the Server Name setting supports wildcard strings containing the asterisk (*) character. For example, *.domain.com matches a.domain.com or a.bc.domain.com, but it does not match domain.com)."

9 Replies

  • Sajjadm, hello.

    Can you share SSL Profiles and vs text configuration?

    • iamsajjad's avatar
      iamsajjad
      Icon for Cirrus rankCirrus

      Thanks for responding. Some sensitive info retracted/altered. Here is the gist of it:

      ltm virtual srv404s_services_http_443 {
      destination 123.x.y.z:https
      ip-protocol tcp
      mask 255.255.255.255
      persist {
      source_addr {
      default yes
      }
      }
      pool srv404s_services_any_http_80_pool
      profiles {
      http_IT-Compliant { }
      srv404s_services_Board-IT-Compliant {
      context clientside
      }
      srv404s_services_Board-IT-Compliant-ExtraSANs {
      context clientside
      }
      tcp { }
      }
      rules {
      SNAT-201to201
      }
      source 0.0.0.0/0
      translate-address enabled
      translate-port enabled
      vlans {
      ...
      }
      vlans-enabled
      }

       

       

      ltm profile client-ssl srv404s_services_Board-IT-Compliant {
      app-service none
      cert none
      cert-key-chain {
      ECDSA-services.com_ESDC-Intermediate_0 {
      cert ECDSA-services.com.crt
      chain ESDC-Intermediate
      key ECDSA-services.com.key
      }
      }
      chain none
      cipher-group IT-Compliant
      ciphers none
      defaults-from equite.com
      inherit-ca-certkeychain true
      inherit-certkeychain false
      key none
      passphrase none
      sni-default true
      }

       


      ltm profile client-ssl srv404s_services_Board-IT-Compliant-ExtraSANs {
      app-service none
      cert-key-chain {
      ECDSA-services.com_Extra_SANs_canlearn_ECDSA-Intermediate_0 {
      cert ECDSA-services.com_Extra_SANs_canlearn
      chain ECDSA-Intermediate.crt
      key ECDSA-services.com_Extra_SANs_canlearn
      }
      }
      cipher-group IT-Compliant
      ciphers none
      defaults-from clientssl
      inherit-ca-certkeychain true
      inherit-certkeychain false
      }

      Thanks,

       

      SajjadM

  • Seems that configuration is fine.

    I'd try to capture traffic to make sure that client provide proper hostname in SNI and server responses with proper certificate. 

    • iamsajjad's avatar
      iamsajjad
      Icon for Cirrus rankCirrus

      I see the server name in SNI extension of Client Hello. But, the F5 server hello presenting the first (default) cert. 

  • What software version do you use?

    Could you try to fill in Server Name field in srv404s_services_Board-IT-Compliant-ExtraSANs profile with hostname?

    And just to be on the safe side, change srv404s_services_Board-IT-Compliant-ExtraSANs profile option defaults-from to equite.com, to make it almost similar with profile client-ssl srv404s_services_Board-IT-Compliant

    • iamsajjad's avatar
      iamsajjad
      Icon for Cirrus rankCirrus

      14.1.4

      Thanks for pointing that out. We are counting on relying on SANs to pick up the cert. Otherwise, we are talking about dozens of SANs in 2nd cert alone.

  •  

    About common name field, it was suggestion. According to link below in 14.1.4 version it isn't necessary. F5 matches SNI with SAN list.

    Unfortunately, I don't have any more ideas how to solve it. Looks like a bug and reason to open a support case. 

    https://support.f5.com/csp/article/K13452

    "For Server Name, enter the name of the HTTPS site.

    Note: Beginning in BIG-IP 11.6.0, if you leave Server Name blank, the BIG-IP system reads the Subject Alternative Name (SAN) from the certificate. For versions prior to BIG-IP 11.6.0, if you leave Server Name blank, the BIG-IP system reads the Common Name (CN) from the certificate. Additionally, the Server Name setting supports wildcard strings containing the asterisk (*) character. For example, *.domain.com matches a.domain.com or a.bc.domain.com, but it does not match domain.com)."

    • iamsajjad's avatar
      iamsajjad
      Icon for Cirrus rankCirrus

      Yep! we went the route opening a case. My love and hate relation starts when it hits a bug. Shall keep you all posted if there is any resolution. Head scratcher indeed.