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.
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.