cert question-Impact of changing the web-security-parameters

[Austin Sabio]

Hello,

Meeting the new standards of our cert vendor requires modifying the state/province value from the abbreviation to the full name (e.g from CA to California).

This can be achieved by setting the web security certificate information for the operating system.

set web-security orgunit orgname locality state

https://community.cisco.com/t5/collaboration-voice-and-video/cucm-uploading-ccmadmin-web-gui-certificates/ta-p/3120166

I am looking for your assistance to determine the potential impact of changing such field 'state' such as:

1. All self-signed certificates have to be regenerated
2. All associated services have to be restarted
3. Possibility of breaking license MAC which requires all cluster licenses to be re-hosted
4. This will overwrite any CA-signed certificate previously imported

Could you please comment on above four points?

Following are the two warnings received in my lab.

WARNING: This operation creates self-signed certificate for web access (tomcat) with the updated organizational information.  However, certificates for other components (ipsec, CallManager, CAPF, etc.) still contain the original information. You may need to re-generate these self-signed certificates to update them.

Regenerating web security certificates please wait ...

WARNING: This operation will overwrite any CA signed certificate previously imported for  tomcat

Proceed with regeneration (yes|no)?

Things to know about the production environment: 

• Clusters are 1 Pub /4 Subs via standard SME design
• UCM version is 11.5
• Only Tomcat and CallManager are CA-signed
• Unsecure /Non-Mixed Clusters and No SSO

Thanks.

-Austin

[Jaime Valencia · Accepted solution]

All self-signed certificates have to be regenerated

Yes if you want them to contain that new info, you'll end up with self-signed certificates, regardless if you had self-signed or CA signed before the procedure after regenerating the certs.

All associated services have to be restarted

Correct, you'll get the necessary warnings and messages of what services need to be restarted, per each certificate.

Possibility of breaking license MAC which requires all cluster licenses to be re-hosted

Nope, license MAC was dropped way back on 9.x when ELM/PLM started being used.

This will overwrite any CA-signed certificate previously imported

See first answer.

[Austin Sabio]

Thank you Jaime for the quick response. I appreciate it.

**Giving the fact:

==========================================================

Tomcat: ca-signed will expire by 11/2019

call manager: ca-signed will expire by 11/2019

all TVS, IPSEC, and CAPF: self-signed certs will expire in 7/2020.

and based on the lab result,

A-the process of updating web-security parameters has to be on all nodes/VMs.

B-all new future CSRs will contain the new info for all cert types.(confirming https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp47839/?rfs=iqvred)

I have additional questions/concerns, seeking your comments:

==========================================================

//TOMCAT

1- Tomcat cert is CA signed - Once the web-security parameters are updated following the prompts - only Tomcat will be affected -it will regenerate Tomcat cert as self-signed (with proper restart). Tomcat cert is now self-signed with new web-security attributes. [create new CSR ---obtain the new CA tomcat cert ---install it].

//CALLAMANAGER

2- Callmanager cert is CA signed - after updating the web-security parameters Callmanager cert will remain, containing old web-security parameters info due to no cert regeneration

[create new CSR ---obtain the new CA call manager cert ---install it].

//TVS, IPSEC, and CAPF

3-Since I am planning to leave all other certs TVS, IPSEC, and CAPF (these are self-signed certs will expire in 7/2020)  with no regeneration- these certs will contain the old info of web-security parameters. Any potential impact on the phones? certainly when experiencing [Next cluster phone rest/ ITL rest].

Thanks

-Austin

[Austin Sabio]

Jaime, any comment certainly on the impact of not renewing the non-expired self-signed certs such as TVS, IPSEC, and CAPF? also if we restart the VMs or the associated services down the road without re-generating the self-signed certificates.

Thanks.

-Austin

[ShawnA1229]

Austin/Jamie,

I am currently facing the same issue. Can you let me know how things turned out for you? Was it OK to simply update the tomcat cert using web-security through CLI and this will not touch the CallManager or TVS, IPSEC, and CAPF cerficicates? Did everything operate properly while having mixed certificates in this nature?

How did the system behave after a server reboot (if you performed one since this change)? Did this break the CallManager certificate or TVS, IPSEC, and CAPF or any others for that matter?

I understand that all future CSRs will use the new information (i.e. State fully spelled out), but until we decide to generate CSRs for those they should work fine correct?

Thank you for any information you can provide here.

[Austin Sabio]

I am currently facing the same issue. Can you let me know how things turned out for you? Was it OK to simply update the tomcat cert using web-security through CLI and this will not touch the CallManager or TVS, IPSEC, and CAPF cerficicates? Did everything operate properly while having mixed certificates in this nature?

After going through the whole process. the modified system info (via cli web-security) was overwritten by the new cert (contained the old info) so I am back to point zero. next year, I need to update this again via (cli web-security). 

That CLI process didn't affect any other certs as noted in the warnings. 

WARNING: This operation creates self-signed certificate for web access (tomcat) with the updated organizational information.  However, certificates for other components (ipsec, CallManager, CAPF, etc.) still contain the original information. You may need to re-generate these self-signed certificates to update them.

Regenerating web security certificates please wait ...

WARNING: This operation will overwrite any CA signed certificate previously imported for  tomcat

Proceed with regeneration (yes|no)?

Note, it affected Jabber by converting it to self-signed cert. End-users had to accept to self-signed certs. 

The conclusion is - typically, this change is performed to the 'answer file' but cisco provides a way to modify these parameters via 'set web-security orgunit orgname locality state'

This is done per cert type based. This is an informative field. The certificates are still the same, they use same private key- just their web-security attributes will be updated. In other words, to update the cert info - use the web-security cli. read Jaime's response. 

The impact, is defined by the cert type and the regeneration process. with that being said, the impact of restarting Cisco Tomcat – means no access to the web GUI, and all HTTPS services will fail, including Extension Mobility, SSO, and Jabber logins will fail.

How did the system behave after a server reboot (if you performed one since this change)? Did this break the CallManager certificate or TVS, IPSEC, and CAPF or any others for that matter?

we didn't perform any system restart - btw we are not expecting any issues related to this as I stated before, all certs are still using same old attributes. 

I understand that all future CSRs will use the new information (i.e. State fully spelled out), but until we decide to generate CSRs for those they should work fine correct? 

They should contain the new info- it should be working fine. 

I always recommend to lab things in advance and open a preventive TAC case to identify proper procedure and impact. 

I hope this helps. 

Thanks. 

-Austin

[ShawnA1229]

Austin,

Thank you for the prompt reply. This is very helpful information.