toomas_aas Absent Member.
Absent Member.
7138 views

CRL Decode Error verifying server certificate

Due to a recent disaster, I had to create new tree CA on our OES Netware server (Netware 6.5 SP8, eDirectory 8.8.5 patch 6) - server MAIN. I did not immediately create new certificates for all the servers in the tree and all services so far seem to be working fine with certificates issued by the old CA. But I don't want to run in this mode forever (or until the old server certificates expire). So I started by creating new certificates for one server (different from the one hosting the tree CA) which is not used much - server BACKUP. I ran PKIDIAG in fix mode and created new certificates, which went without errors.

I rebooted the server and re-ran PKIDIAG in diagnostic mode - it found 0 errors.

I also tested ldaps connection against BACKUP using the diagpwd tool with the new CA certificate. That went fine.

But when I try to validate the new certifcate in iManager (modify the SSLCertificateDNS object, choose 'Self signed certificate', tick checkbox in front of "SSL CertificateDNS" and click 'Validate'), it returns: "Invalid: CRL Decode Error".

Can this be because I am running iManager on server MAIN which still has the old certificate issued by the old CA? I don't have Tomcat running on BACKUP, so I can't easily test if this is the case.

Another theory was that my browser does not trust the new tree CA, but importing the new root certificate into browser's trusted root certificates store did not alleviate the problem.
Labels (2)
0 Likes
8 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: CRL Decode Error verifying server certificate

A Certificate Revocation List (CRL) is the mechanism by which an
administrator can invalidate a certificate before its natural expiration
datetime and it is stored in conjunction with the CA, and then made
available on the CA in attribute that hold URLs for LDAP or HTTP
connections which point clients to a CRL Distribution Point (CRLDP). The
result is that clients can, if they do not have a new-enough copy, pull
down the CRL from the CA's CRLDP and then look for the certificate
presented to them by a server to see if, despite being valid time-wise, it
has been revoked for other reasons (compromise, for example).

At this point I would check two things:

1. Does your current CA have CRLDPs defined? If so, where do they point?
2. Did your old CA have CRLDPs defined? You can see this by looking at
the Trusted Root certificate on existing certificates from your old CA
using iManager or ConsoleOne.

I am guessing #2 will be true, and the fix is probably to simply give
iManager new certificates to use minted from your new/existing CA so that
either the CRL DPs are valid, or gone entirely, meaning the client will no
longer have a reason to fail the CRL check. My guess is that the decode
error happens because the existing CRLs that are available do not match
the old CA (stored with your older certificates) and therefore cannot be
properly decoded, which is a valid error.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
toomas_aas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

Actually, it was the new CA that had a CRL configuration problem. When looking at the newly issued certificate I noticed that it has an extension named "CRL Distribution Points", which point to "http://MAIN_SERVER:80/crl/CRL_1.crl" and "ldap://MAIN_SERVER:389/CRL_1,CRL_1 - Configuration.CRL Container.Security". None of the certificates issued by the old CA had such extension. Looking into SYS:\apache2\htdocs\crl I did not find a file named CRL_1.crl there. There was another .crl file there with a timestamp indicating that it had been created by the old CA shortly before it died.

I went to iManager Novell Certificate Server - Configure Certificate Authority - CRL. There was a CRL configuration named CRL_1, but it showed no datestamps indicating last and next update of the crl. I defined a new CRL configuration, made it active and verified that corresponding .crl file was created under sys:\apache2\htdocs\crl. Then I issued new certificates to the BACKUP server, and they can now be validated successfully.
0 Likes
nlandas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

I ended up with a very similar problem after fixing the certificates on my iPrint server. My CA was not removed but it had an old invalid CRL listed. I cleaned up the old invalid CRL and created a new valid one. It's properties show it to be valid and it's files were created under /opt/novell/eDirectory/data/dib/SYS:htdocs which took me a while to find since SYS: is Netware not Linux. ;^)

However, when I reissue certificates they still have an invalid CRL message when validated. I've even completely deleted the certificates from the offending server and recreated them with ndsconfig upgrade. I have also reloaded ndsd on the server that holds the CA.

Can anyone tell me what I am missing. I really need to fix this as something related to certificates is keeping my iPrint server from validating via ldap but I'll leave that to another thread. Thanks.
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: CRL Decode Error verifying server certificate

nlandas;2318585 wrote:
I ended up with a very similar problem after fixing the certificates on my iPrint server. My CA was not removed but it had an old invalid CRL listed. I cleaned up the old invalid CRL and created a new valid one. It's properties show it to be valid and it's files were created under /opt/novell/eDirectory/data/dib/SYS:htdocs which took me a while to find since SYS: is Netware not Linux. ;^)

However, when I reissue certificates they still have an invalid CRL message when validated. I've even completely deleted the certificates from the offending server and recreated them with ndsconfig upgrade. I have also reloaded ndsd on the server that holds the CA.

Can anyone tell me what I am missing. I really need to fix this as something related to certificates is keeping my iPrint server from validating via ldap but I'll leave that to another thread. Thanks.


this one should help:

https://www.novell.com/support/kb/doc.php?id=7006855

Cleaning up the dibdir is likely the key.
0 Likes
nlandas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

mathiasbraun;2318588 wrote:
this one should help:

https://www.novell.com/support/kb/doc.php?id=7006855

Cleaning up the dibdir is likely the key.




Thanks for the reply.

I did see that one but was nervous as Novell's other documentation said not to manually do so but I followed their TID to the letter. Armed with the recommendation, I carefully deleted all the CRL objects from the Security container, moved all the crl files from the dib directory to a tmp dir, and I even did the same in the apache2/htdocs dir just to make sure they'd be gone. Then I restarted ndsd and recreated the CRL on the CA, made it active, etc.

I then repaired and forced replace the default certificates on the same server and they sitll report Invalid: CRL Decode Error.

I could delete them and do another ndsconfig upgrade but I suspect I'll still see the same error. How can it be invalid when it says its successfully renewed and active. I can't even get the server who is the CA to replace and validate it's own certificates without the CRL Decode Error.

I am so at a loss on this one. I can't clean up my other issue until I'm certain that my certificates are all valid. Any other ideas? They are truly appreciated.


Any idea how I test and confirm the Distribution points? Are those required for the other servers to validate the certificates CRL? I really don't want to be a certificate expert just to run file and printer services. ;^D
0 Likes
nlandas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

Ok, so apparently from reading many pages, it may be my CRL Distribution points that need to be fixed. Apparently, the defaults do nor work?

Does anyone know how to refer to the crl files sitting in the SYS:apache2/htdocs via a URL using the apache server on my OES2 box? Is that possible or do I need to copy the file somewhere else and what happens when it expires in 52 weeks if I do?

Thanks.
0 Likes
nlandas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

So what I ended up doing as a temporary fix was to place my CRL onto a web server and point to it there in the Distribution lists. For the life of me I couldn't figure out how to modify the OES2 servers apache config to have an alias that went to the SYS:apach2/htdocs folder so that I could refer to the crl directly where it is regenerated.

Shouldn't the CRL by default be placed in a location where the default distribution points can access it? It seems like that would at least work by default?

If anyone can tell me what apache2 file to edit, without breaking my OES welcome page, so that say http://serverip/crl/mycrl.crl would refer to the correct location, it would be a big help to me. Thank you.
0 Likes
Highlighted
nlandas Absent Member.
Absent Member.

Re: CRL Decode Error verifying server certificate

nlandas;2318585 wrote:
I ended up with a very similar problem after fixing the certificates on my iPrint server. My CA was not removed but it had an old invalid CRL listed. I cleaned up the old invalid CRL and created a new valid one. It's properties show it to be valid and it's files were created under /opt/novell/eDirectory/data/dib/SYS:htdocs which took me a while to find since SYS: is Netware not Linux. ;^)

However, when I reissue certificates they still have an invalid CRL message when validated. I've even completely deleted the certificates from the offending server and recreated them with ndsconfig upgrade. I have also reloaded ndsd on the server that holds the CA.

Can anyone tell me what I am missing. I really need to fix this as something related to certificates is keeping my iPrint server from validating via ldap but I'll leave that to another thread. Thanks.


For those that end up on this thread and may still be confused what I ended up doing was setting up a new CRL. In this CRL the CRL File path was set to apache2/htdocs/crl and it was tested to successfully issue a new CRL. I then copied the CRL with a script to the apache server root on the CA server so that it was accessing via apache.

Then I added as CRL Distribution Points
http://localip:80/crl/CRL_1.crl
http://localdomain:80/crl/CRL_1.crl

The script copies the file from /var/opt/novell/eDirectory/data/dib/SYS:apache2/htdocs/crl/CRL1.crl to /srv/www/htdocs/crl/CRL_1.crl
then chmods the file for access.

Maybe I've missed something but by doing this all the other servers can use the CA CRL Distribution points to validate the certificates CRL and they are listed as valid.

I then schedule the script to run using crontab.

So when the server reissues the CRL the new one is copied to the Distribution points.

Perhaps, a simpler solution is to set the path directly to the /srv/www/htdocs/crl/ location but for some reason I thought it needed to remain in SYS:apache2/htdocs/.

I know this is an old thread but I see others referencing it so hopefully someone can chime in. This setup works for me as the CRL reissues the certificates stay valid. Overall, confusing to maintain and repair when broken.
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.