We use our own PKI to generate identity certs for Session Manager and this is the first time they're going to expire. The new certificates have been generated by our folks. When I go to managed elements and into the Session Manager Identity Cert page, am I selecting 'replace' and then import of 3rd party cert? If that's the process and after you commit, is that all that is required or the Session Manager has to be rebooted?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ASM Identity Certificates
- Thread starter trilogy8
- Start date
I'd reckon it'd take live on the fly
Beware - initTM literally initializes all trust management on SM - as in, flush all identity AND trusted certificates and re-enroll to SMGR from scratch.
So, regardless of SM's identity cert, if you let the management cert it's using for database replication to SMGR expire, you'll need to initTMa and flush all trusted certs - including those of your PKI's CA.
So, if you have TLS trunks from SM to your Exchange UM for example and SM needs to TLS HELLO to UM and get a MS UM cert signed by the MS CA, that'll fail if you had to initTM because the SM-->SMGR management cert expired and you did an initTM without adding the MS CA cert as a trusted authority later.
Schedule permitting, I'll see if I can try in my lab tomorrow to replace an identity cert without bouncing the SM. What release are you on?
Beware - initTM literally initializes all trust management on SM - as in, flush all identity AND trusted certificates and re-enroll to SMGR from scratch.
So, regardless of SM's identity cert, if you let the management cert it's using for database replication to SMGR expire, you'll need to initTMa and flush all trusted certs - including those of your PKI's CA.
So, if you have TLS trunks from SM to your Exchange UM for example and SM needs to TLS HELLO to UM and get a MS UM cert signed by the MS CA, that'll fail if you had to initTM because the SM-->SMGR management cert expired and you did an initTM without adding the MS CA cert as a trusted authority later.
Schedule permitting, I'll see if I can try in my lab tomorrow to replace an identity cert without bouncing the SM. What release are you on?
- Thread starter
- #3
I'm on SM 7.0.1. I am using Identity certs for the security module https and SIP. The SPIRIT, mngt and websphere services are all using the SMGR certs. Not sure if that matters. You're saying if the replaced certs didn't automatically take and SM had to be rebooted that I'd have to re-import back the trusted and identity certs to get my trunks to CM back up? That would be a drag.
No, i think they'd take almost on the fly. I think SM or any equivalent java application ought to be able to just offer up the new cert without kicking the application.
It's those management certs you have to worry about - those will cause an outage to fix if you don't renew them through inventory-->manage identity certs.
Certs expiring is a weird thing. Had it happen once and all the phones stayed up and were fine. That's because the cert is only presented from the server to the client to open the TLS connection - not to maintain the connection. So, once the cert expired, everything was fine as long as the phones didn't have to send another TLS CLIENT HELLO. If any of those phones bounced, they wouldn't come back.
In another case, I had a AAEP. AAEP normally generates a self signed cert. You could use SMGR signed ones if you went to the trouble of doing a cert enrollment, but if you were lazy, you could use AAEP's self signed certs. You could add the SMGR CA cert to AAEP such that when AAEP sends TLS CLIENT HELLO to SM - like when outdialing a call - that AAEP will trust the cert SM offers.
In that AAEP case, we also had to take the self-signed authority cert of AAEP and import it into SMs' trusted root CAs so that when SM sent TLS CLIENT HELLO and got AAEP's cert, our SM would be able to trust it.
Then we forgot to renew the mgmt cert on SM. That meant we couldn't manage it via SMGR anymore. The only way out of that is initTM on the SM. initTM means literally what it says - initialize all trust management - as in, flush your trust stores and key stores, and in, stop trusting that AAEP CA cert - or in your case - stop using that customer PKI cert on the SIP interface. Please generate new keys and cert requests to SMGR. After a initTM, your certs will be good again for 2 years - just as if you'd done it via the inventory - but initTM is a hammer that defaults all cert configs - which in your case might cause you an outage if you're relying on SM offering that customer PKI cert on the SIP interface.
I'd say do it all in a maintenance window anyway, but beware the mgmt certs!
It's those management certs you have to worry about - those will cause an outage to fix if you don't renew them through inventory-->manage identity certs.
Certs expiring is a weird thing. Had it happen once and all the phones stayed up and were fine. That's because the cert is only presented from the server to the client to open the TLS connection - not to maintain the connection. So, once the cert expired, everything was fine as long as the phones didn't have to send another TLS CLIENT HELLO. If any of those phones bounced, they wouldn't come back.
In another case, I had a AAEP. AAEP normally generates a self signed cert. You could use SMGR signed ones if you went to the trouble of doing a cert enrollment, but if you were lazy, you could use AAEP's self signed certs. You could add the SMGR CA cert to AAEP such that when AAEP sends TLS CLIENT HELLO to SM - like when outdialing a call - that AAEP will trust the cert SM offers.
In that AAEP case, we also had to take the self-signed authority cert of AAEP and import it into SMs' trusted root CAs so that when SM sent TLS CLIENT HELLO and got AAEP's cert, our SM would be able to trust it.
Then we forgot to renew the mgmt cert on SM. That meant we couldn't manage it via SMGR anymore. The only way out of that is initTM on the SM. initTM means literally what it says - initialize all trust management - as in, flush your trust stores and key stores, and in, stop trusting that AAEP CA cert - or in your case - stop using that customer PKI cert on the SIP interface. Please generate new keys and cert requests to SMGR. After a initTM, your certs will be good again for 2 years - just as if you'd done it via the inventory - but initTM is a hammer that defaults all cert configs - which in your case might cause you an outage if you're relying on SM offering that customer PKI cert on the SIP interface.
I'd say do it all in a maintenance window anyway, but beware the mgmt certs!
- Thread starter
- #5
Luckily the services on the SM that are not using my PKI don't expire until 2021. If the process is the go to each ASM via managed elements and then configure identity certs, it looks like you have to do a replace on each service. That's a bit repetitive to have to upload the same cert on each ASM 2X. I have to apply a new SBC cert as well, but that looks pretty straight forward.
jimbojimbo
Vendor
Certificates will auto-renew (assuming your release is relatively current since some older 6.x releases had a problem with this. Same with System Manager although you do need to schedule a reboot.
- Status
Similar threads