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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SMGR C/A

Status
Not open for further replies.

wpetilli

Technical User
May 17, 2011
1,877
US
The favorite topic of everyone.. certs. We are about to move forward with a complete refresh and the topic of certs has come up. Our security teams mandate the use of our internal PKI for all infrastructure. With that comes having to set reminders for elements like servers for the renewal process. They've also shortened the life span of the certs to 13 months. We brought back to the table the use of SMGR as the C/A for the Avaya stack or potentially made a subCA of our current PKI. I'm not finding this documented, but does using SMGR in these fashions automate the stacks renewal process? And does it have the flexibility to shorten the cert validity periods to the 13 months?
 
You can change the validity period. The EJBCA is basically a canned open source CA, so you can do lots with it. Not that Avaya would support you in using it in weird ways, but it is a fully functional CA.

You can...
I'd leave it well enough alone and use SMGR only for element management and use your own on the interfaces touched by client endpoints - SM100 etc
 
I'm surprised you say that. I'd have thought the opposite.
 
I'm reading alot about utilizing a public cert on the SBC and internal stuff everywhere else. I see how a public cert on the sbc makes it way simpler for windows clients and ios devices, but how does that apply to remote hard phones. Especially where those get an identity cert and do mutual auth.
 
If you have remote hard phones thru the SBC, you can still have an identity cert per phone and have the SBC force mutual TLS and only trust identity certs from your CA.

The SBC can offer GoDaddy but still require an identity cert from your PKI to do a handshake.

I'd put a GoDaddy on the SM, PS, AADS interfaces on the inside. Otherwise you'll pull your hair out making iOS happy with what SMGR provides to SMs and stuff.

The 1 cert can have many subject alternative names. A dozen isn't going to hurt anything.

Go check this out: DNS Name=1000-sans.badssl.com
DNS Name=wowmoarsans2.badssl.com
DNS Name=wowmoarsans3.badssl.com
DNS Name=wowmoarsans4.badssl.com
DNS Name=wowmoarsans5.badssl.com
DNS Name=wowmoarsans6.badssl.com
DNS Name=wowmoarsans7.badssl.com
 
I guess we can continue to use our own PKI, even on the SBC since our laptops and mobile devices have our root and subCA's. The SCEP identity cert process is a bit of a drag and would have loved to have been able to simplify that. The public cert seems mostly beneficial to allow non company devices to work.
 
You can offer the public cert and require the other side to offer one of your certs the SCEP enrollment provided.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top