Highlighted
Absent Member.
Absent Member.
957 views

LDAP SSL

GW12.0.3
We had an issue where our GroupWise LDAP Authentication stopped working.
To fix it, we turned off LDAP SSL on port 636.
In ConsoleOne the objects for the Servers
DNS AG xxx
IP AG xxx
SSL CertificateDNS-xxx
SSL CertificateIP-xxx
all show the Certificate will not expire until March of 2020, and do Validate ok.
but....
In iManager "Novell Certificate Access", "Server Certificates" they are Expired.
but they expired 2 weeks ago. (Must have had a grace period)

What is the correct procedure to update the Certs in iManager?
I find conflicting info. Some sources say to use the "Replace" feature in the Server Certificates Task, some say to go to "Novell Certificate Server" task then select "Repair Default Certificate".
No Users authenticate to NDS but a few admin staff. We don't use File or Print sharing, Only GroupWise Functions.

What is the correct way to refresh the Certs for a date in the future?
Thank You!
Labels (2)
0 Likes
12 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: LDAP SSL

Hi,

Here's a pretty good script: https://www.novell.com/communities/coolsolutions/cool_tools/certificate-recreation-script-oes1-and-oes2/

Let us know if you need further assistance.

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...
Highlighted
Absent Member.
Absent Member.

Re: LDAP SSL

Laura Thank you for the help.
The script seems to be for OES. My Certificate server is SLES 11sp3, my LDAP Servers are two Netware 6.5 servers and a SLES 11sp3.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: LDAP SSL

Hi,

Specifically for the GroupWise certificates: https://www.novell.com/documentation/groupwise2012/gw2012_guide_admin/data/ak9e3ju.html#bsy5qx9 though I don't that's what you are looking for!

On the NetWare servers you can use pkidiag for repairs/validation

I'll try find the iManager stuff for you.

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
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: LDAP SSL

Hi

Perhaps this will help: https://www.netiq.com/support/kb/doc.php?id=7013142

Also points to some other TID's

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
Highlighted
Absent Member.
Absent Member.

Re: LDAP SSL

I guess my confusion is that in iManager | Roles & Tasks | Novell Certificate Server | Configure Certificate Authority | Select Certificates | Check the Self Signed Certificate | Select Validate.
The "OU=Organizational CA.O=xxxx" and "Self Signed Certificate" are both Valid and expire March 9 2020.
But in iManager | Roles & Tasks | Novell Certificate Access | Server Certificates | All of the certs listed
DNS AG xxx
IP AG xxx
SSL CertificateDNS-xxx
SSL CertificateIP-xxx
are "Invalid: Certificate Expired"
So should I still do TID 7013142 ?
Would this fix the expired certs?



>>> laurabuckley<laurabuckley@no-mx.forums.novell.com> 3/21/2015 5:36 AM >>>


Hi

Perhaps this will help:
https://www.netiq.com/support/kb/doc.php?id=7013142

Also points to some other TID's

Cheers,


--
Laura Buckley
Technical Consultant
IT Dynamics, South Africa

If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below...
------------------------------------------------------------------------
laurabuckley's Profile: https://forums.novell.com/member.php?userid=122
View this thread: https://forums.novell.com/showthread.php?t=482637
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: LDAP SSL

Hi

It would appear that your Certificate Authority is valid, so that TID won't do the trick for you.

To repair your server certificates try the following:

1. Go into iManager.

2. Go 'Novell Certificate Server'.

3. Choose 'Repair Default Certificates'.

4. Choose for your tree one or more servers that need the certificates to be repaired/renewed and click on OK.

5. Click on Next.

6. Select 'Yes All Default Certificates will be overwritten' and click on 'Next'.

7. Click on 'Finish.'

8. When this process is completed, click on 'Close'.

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...
Highlighted
Absent Member.
Absent Member.

Re: LDAP SSL

Laura
The procedure you listed worked great. Thank You !
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP SSL

In article <550FB481.043F.00C6.1@mydomain.org>, Dkamp wrote:
> I guess my confusion is that in iManager | Roles & Tasks | Novell Certificate Server | Configure Certificate Authority

| Select Certificates | Check the Self Signed Certificate | Select Validate.
> The "OU=Organizational CA.O=xxxx" and "Self Signed Certificate" are both Valid and expire March 9 2020.
> But in iManager | Roles & Tasks | Novell Certificate Access | Server Certificates | All of the certs listed

...
> Are "Invalid: Certificate Expired"


These are pointing to two different parts of the whole PKI infrastructure.
The first part shows that your CA (Certificate Authority, aka THE root and most key part of the PKI infrastructure for
your system.) is good for another 5 years and was created 5 years ago. So at this stage you can ignore that part other
than put in a calendar reminder for early February 2020 that you'll have to get ready to re-cert the whole cert tree.
Those root certs by default are good for 10 years.

The Server certs by default are only good for 2 years and those you need to re-mint as per TID 7000075
https://www.novell.com/support/kb/doc.php?id=7000075
missing are the restarting ldap commands of which there are a couple ways:
ndstrace, modules, unload ndlap, load nldap
or
ndstrace -c 'unload nldap'
ndstrace -c 'load nldap'
or
nldap -u / nldap -l

after you have restarted ldap with the new certs, you will have to tell Tomcat about it so that iManager can work with it
with the command:
tckeygen -k

then restart apache and tomcat so that they are using the new cert.


> So should I still do TID 7013142 ?

Fix the certs first and then recheck things. This might have already been done previously and mostly refers to that the
public key for the root certificate.

> Would this fix the expired certs?

I see that got it all working, hope this all helps you understand more of what is behind it and clear up any lose ends
from what you've followed through so far.


You might ask "Why do certificates expire?"
- All certificates have expiration dates to ensure that the window of exposure, should the certificate be compromised, is
limited. It also ensures that as systems are upgraded, that newer encryption methods get included and old ones are retired
(POODLE was such a rushed issue when an new hole in an old encryption method was found)
TID 7003514 is also a good read on the topic not that it is directly a worry for you from what you've mentioned but might
be relevant to your Webaccess. https://www.novell.com/support/kb/doc.php?id=7003514

Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please show your appreciation by clicking on the star
below. Thanks!

___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP SSL

Andy,

Am 30.03.2015 um 03:45 schrieb Andy Konecny:
> The Server certs by default are only good for 2 years and those you need to re-mint as per TID 7000075
> https://www.novell.com/support/kb/doc.php?id=7000075
> missing are the restarting ldap commands of which there are a couple ways:
> ndstrace, modules, unload ndlap, load nldap
> or
> ndstrace -c 'unload nldap'
> ndstrace -c 'load nldap'
> or
> nldap -u / nldap -l


Note that unfortunately, eDir itself reads the certs at start time (not
ldap), so above doesn't suffice to get the new certs active. You'll have
to restart ndsd /rcndsd restart) as a whole, which unfortunately means
that all file access to the server will be interrupted shortly. 😞

> after you have restarted ldap with the new certs, you will have to tell Tomcat about it so that iManager can work with it
> with the command:
> tckeygen -k


That, however isn't necessary usually, *unless* the CA aka root cert has
changed. In which case a "namconfig -k" is necessary too.


Also, ndsd on restart exports it's certs to the filesystem for all
others to use (if they care), including apache and tomcat. Another point
plus restarting ndsd as a whole. Or play it safe, and if you can, reboot
the whole server.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: LDAP SSL

Massimo Rosen wrote:

> > The Server certs by default are only good for 2 years and those you
> > need to re-mint as per TID 7000075
> > https://www.novell.com/support/kb/doc.php?id=7000075 missing are
> > the restarting ldap commands of which there are a couple ways:
> > ndstrace, modules, unload ndlap, load nldap or
> > ndstrace -c 'unload nldap'
> > ndstrace -c 'load nldap'
> > or
> > nldap -u / nldap -l

>
> Note that unfortunately, eDir itself reads the certs at start time
> (not ldap), so above doesn't suffice to get the new certs active.
> You'll have to restart ndsd /rcndsd restart) as a whole, which
> unfortunately means that all file access to the server will be
> interrupted shortly. 😞


Are you sure about that? I recently had a Filr issue which I
discovered was because the certs had expired. I temporarily switched
from LDAPS to LDAP to get Filr going, then eventually when I fixed the
default server certs in iManager I just did nldap -u / nldap -l and was
able to switch Filr back to LDAPS without any problems. I didn't have
to restart ndsd.

--
Your world is on the move. http://www.novell.com/mobility/
Supercharge your IT knowledge. http://www.novell.com/techtalks/

Joe Marton Emeritus Knowledge Partner
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: LDAP SSL

In article <t98Sw.6189$Yv2.5478@novprvlin0913.provo.novell.com>, Massimo Rosen wrote:
> eDir itself reads the certs at start time (not
> ldap), so above doesn't suffice to get the new certs active. You'll have
> to restart ndsd /rcndsd restart) as a whole

hmm, then why do I see ldaps using the new certs when I've only restarted the nldap bit?

>
> > after you have restarted ldap with the new certs, you will have to tell Tomcat about it so that iManager can work with it
> > with the command:
> > tckeygen -k

>
> That, however isn't necessary usually, *unless* the CA aka root cert has
> changed. In which case a "namconfig -k" is necessary too.

I've had tomcat & LUM break after a regular cert reissue if I missed those steps, sometimes only noticed after a reboot, so
we clearly have a missing piece of this puzzle.

> Also, ndsd on restart exports it's certs to the filesystem for all
> others to use (if they care), including apache and tomcat. Another point
> plus restarting ndsd as a whole. Or play it safe, and if you can, reboot
> the whole server.

The reboots are when we find the gaps in the key propagation. Perhaps this is something that has been fixed in newer
versions of eDir and/or OES, so this does beg of some testing to see where this came in.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please show your appreciation by clicking on the star below.
Thanks!

___
“i’ve sworn an oath of solitude til the blight is purged from these lands”
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
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.