Forum Discussion
jwckauman
Altostratus
AltostratusRenewed & Overwritten certificate not being used by some clients
We renewed our primary SSL Certificate for the bulk of our SSL Profiles and overwrote the existing cert (which was expiring). In our testing, we see most of our internal clients using the new certif...
jwckaumanAltostratus
AltostratusThank you! Do u happen to know what causes the connections to complete or renegotiate? And what effect does restarting the Traffic Management Microkernel (TMM) have on existing connections?
I don't know for sure if it's all external connections. I know some external connections use the new cert on some of our virtual servers but not others. It's a mixed bag.
CA_Valli
MVP
MVPConnections complete when they either time out or get TCP-FIN packets. This means that when you renew the certifiacte, there's no impact on existing connections (don't need to renegotiate) while all new connections should be able to see new cert already.
Restarting TMM causes traffic disruption and should be done in a maintenance window.
If the problem is on some VS's and not others you might want to take a look at clientSSL profile as well, to confirm that they're correctly referencing the new crt/key pair (which they should if you have overwritten them as you said) and the correct intermediate/root certificates in the trust chain.
- jwckauman
Thank you. Is there any way to force a time-out from the client-side? I happen to have one of the external clients (my home laptop) which shows the new cert on four of our six sites (i.e. virtual servers) but not the other two. (my internal work laptop shows the new cert on all six sites).
If there isn't a way to force a time-out from the client-side, can we do it from the F5 for a specific client session? Or is there a way to generate/force a TCP-FIN packet either at the client or F5? I would like to confirm that my test client (home laptop) can eventually see the new cert on those two remaining sites, without having to restart the TMM.
- CA_Valli
You can't force a timeout from client-side (it will happen if you leave the connection open too long, based on timers set on your F5 profiles) but you can force a connection close.
This is weird behavior - if you see new CRT on the other VS's I'd expect that a NEW connection to the other two should work just fine as well.
I'd like to suggest you to run a packet capture on F5 filtering by your client IP and check what certificate is presented by F5 during SSL handhsake in server-hello packet. If it's the new one, but you still see old cert on client, it's very likely that there is something else between your client and F5 which is presenting you the wrong CRT. You'll need to find this appliance and update cert as well. If the packet shows F5 still presents old CRT, there's a config problem somewhere on F5. Check what clientSSL profile are using the two VS's that don't work and check if all configuration objects (cert, key, intermediate chain) are referenced correctly. If key is password-protected try updating the password on the profile as well.
Hope this helps
CA
- CA_Valli
From F5 you can forcefully drop a client connection running "tmsh delete sys connection cs-client-addr <your client IP> cs-server-addr <VS IP> cs-server-port <VS port>"
https://support.f5.com/csp/article/K53851362 for reference