Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Highlighted
lpphiggp
New Member.
815 views

New server certs not used by NRM

Having recently recreated our CA last December (2012), we issued new certs to most of our servers.
(long story short, our old CA had not yet expired but a tech claimed it had and recreated our CA.. it was actually good until 2014)

I've found that typically, on our OES linux boxes however, when I generate new certs via iManager/Repair default certifidfates, the new certs do not translate over to the cert used by httpstk/Remote Manager.
On this one server, as an example, it's still using an old cert that was issued 2011, and says it's good until 2015.

Do I have to manually export and import the new certs? (and if so, why isn't that built-in to the repair certificates function in iManager?)

Furthermore, this old cert lists no CA in the chain. We definitely had one. This isn't' the first NRM cert I've seen exhibit this behavior either.

How do I get these certs to sync up with the ones the server is actually using in eDirectory?

Thanks
Paul
Labels (2)
0 Likes
4 Replies
Micro Focus Expert
Micro Focus Expert

Re: New server certs not used by NRM

Hi Paul,

As far as I'm aware you do need to export/import the certificates on a Linux based (OES) server.

Here's a good article on how to do it: Recreating Server Certificates on OES Linux - CoolSolutionsWiki

There's also a script available: https://www.novell.com/communities/node/5704/certificate-recreation-script-oes1-and-oes2

Please let us know how it goes.

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
lpphiggp
New Member.

Re: New server certs not used by NRM

Thanks Laura!

Any idea why this functionality is not built into iManager's certificate module?
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: New server certs not used by NRM

Hi

I'm actually not 100% sure ! Perhaps it's time for an enhancement request: http://www.novel.com/rms

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Knowledge Partner
Knowledge Partner

Re: New server certs not used by NRM

lpphiggp;2287456 wrote:
Having recently recreated our CA last December (2012), we issued new certs to most of our servers.
(long story short, our old CA had not yet expired but a tech claimed it had and recreated our CA.. it was actually good until 2014)

I've found that typically, on our OES linux boxes however, when I generate new certs via iManager/Repair default certifidfates, the new certs do not translate over to the cert used by httpstk/Remote Manager.
On this one server, as an example, it's still using an old cert that was issued 2011, and says it's good until 2015.

Do I have to manually export and import the new certs? (and if so, why isn't that built-in to the repair certificates function in iManager?)

Furthermore, this old cert lists no CA in the chain. We definitely had one. This isn't' the first NRM cert I've seen exhibit this behavior either.

How do I get these certs to sync up with the ones the server is actually using in eDirectory?

Thanks
Paul


httpstkd will use the default OES certs.

However, I've seen on MANY occasions:
1) After repairing the SSL certs, I need to reboot the server for things to take effect
and
2) NRM can use LUM. LUM (namcd) has an annoying habit of sometimes not replacing the actual certificate files. In other words, when you repair the eDir SSL cert, do a namconfig -k to re-pull the SSL certs down, it won't actually overwrite the file that's already on the file system that's corresponding to the updated SSL cert. I've (many times) had to manually delete the cert files, and then re-run namconfig -k and restart namcd
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.