System Manager Geo redundancy with 3rd Party certificates 1

[mattKnight]

Hi,

I'm running up a pair of System Managers in a test environment and am having problems with configuring geo redundancy when I use 3rd part signed certifcates.
It works if I try with a standard SMGR build, so I'm sure it is a certificate trust issue. I get the following error in the auotconfig.log file

Mon May 18 16:05:01 BST 2015   SMGR  ::  ErrorMessage=com.nortel.ems.mgmt.security.pki.agent.CertMgmtException\: Server xxxx.yyy.zzzzzzz.ddd.fff did not return a proper certificate chain

I suspect that I need to add a CA to Quantum part of SMGR, but can I find any docs on that?

************************************************
System Manager - Software Information
************************************************

===== Software Update Revision: 6.3.13.10.3336 =====

System Manager 6.3.8.0 Build Number 6.3.0.8.5682
Patch 6.3.8.5108 Build Number 6.3.13.10.3336

any thoughts?

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[jimbojimbo]

Did you correctly configure the /etc/pki/tls/openssl.cnf and include the associated Subject Alternate Names prior to generating the CSR? The System Manager Virtual Hostname would be one of the SAN requirements. Unfortunately Avaya doesn't make certificates easy nor do they have adequate documentation. As an example, the default certificates have been SHA-1/1024 which have been deprecated since January 2014 from a security perspective (See FIPS/FISMA and DISA). Below is a general outline of the applicable part of the openssl.cnf file to be edited on System Manager


basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment,
keyAgreement
extendedKeyUsage=serverAuth, clientAuth
subjectAltName= @alt_names

[alt_names]
DNS.1 = <SMGR FQDN>
DNS.2 = <GR SMGR FQDN> <-This is the Georedundant FQDN and should be added even if not initially installing with GeoRedundancy.

 

[mattKnight]

>Unfortunately Avaya doesn't make certificates easy nor do they have adequate documentation. As an example, the default certificates have been SHA-1/1024

This one of our key reasons for moving away from the default certs

I think I've got the cert right, its a wildcard i.e the SAN is *.domain.tld, which should cover all hosts in that domain.

However, I've just looked at the cert and

#7: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  DigitalSignature
  Key_Encipherment
]

keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment

It looks like I may be missing the nonRepudiation and dataEncipherment uses...

Hmm cert regeneration time possibly...

Thanks

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[mattKnight]

Finally,

I have it working - jolly good thing for labs!

The issue that I had was the the 3rd party certificate that I am using did not have the full trust chain as part of that file. So when I used as an identity certificate in SMGR it was not valid (even though I'd added the intermediate CA and Root CA to the trusted cert store in SMGR

In the end I had to do this on a unix box (handy that I had a SMGR box available)

!! convert my cert's private key to PEM / RSA
openssl rsa -inform pem -outform pem -in /tmp/mycert.key  -out /tmp/mycert_key.pem

!! Build a certificate chain in a PEM format
cat mycert_key.pem mycert_cert.crt myIntermediateCA.crt myRootCA.crt > mycertchain.pem

!! Convert to PCKS12 bundle for import to SMGR
openssl pkcs12 -export -in mycertchain.pem -out mycertchain.p12
 create password when prompted by openssl conversion process

Used the mycertchain.p12 as the identity cert in SMGR and georedundancy started working as it should!


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.