Forum Discussion
iamsajjad
Cirrus
CirrusProblem 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)."
MaximPSajjadm, hello.
Can you share SSL Profiles and vs text configuration?
iamsajjadThanks 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
- MaximP
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.
- MaximP
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
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.
- MaximP
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
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.