• State Not Answered
  • Replies reply
    1
  • Subscribers subscribers
    18
  • Views views
    99
  • Users 0 members are here

NAM 5.1 and OCSP/CRL Checking

Matt Weisberg
 

Word of warning to those of you upgrading to NAM 5.1.  I upgraded a NAM 5.0.4 environment today and after upgrading my IdP wouldn't turn "green". I was getting a warning about one of the certs in the trust store:

X509 Certificate Validation Root Exception: com.novell.nidp.NIDPException: Error processing certificate validations

Looking in the catalina.out, I was seeing errors like this:

javax.naming.InvalidNameException: Invalid name: CRL_1,CRL_1 - Configuration.CRL Container.Security

 

The IdP was completely non-functional.  If I tried to access ANY AG protected resource, I'd get a 300101050 error from the IdP.

I tried re-pushing certificates to no avail.  So I turned up debug logging, and I saw the IdP trying to make some really odd LDAP connections.  This site is using eDirectory as a user store.  The LDAP URIs the server was trying to connect to were in that user store, but they were the cleartext (389) LDAP port, which we don't allow, and the server's short name, which wouldn't resolve.  I couldn't figure out where the heck it was coming from.

Well, it turns out for one of the SAML SPs, I used a certificate minted from the the eDir CA for SAML signing.  I guess NAM 5.1 is more aggressive about OCSP/CRL checking now because that is what it was trying to do, connect to the LDAP URIs defined in the CRL Distribution Points in the eDirectory CA, which of course were not reachable.

I just disabled OCSP/CRL checking in tomcat.conf:

JAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"

And restarted the IdP and everything started working.

Never seen that behavior before (I've certainly had to disable OCSP/CRL before, but not due to this).

I am a bit surprised though that they have not added the ability to disable OCSP/CRL checking in the admin interface already!

Matt

  • 0

    Thanks for sharing. Yet another reason to stay away from 5.1 for a while.

    It is frustrating that Access Manager does not use a soft fail, as most software does. We have more than 200 service providers (SPs) that use a certificate issued by a certificate authority (CA) that operates with OCSP and/or CRL endpoints. During an IdP configuration update, all these endpoints are queried, and we often receive an 'HTTP status code 503' from, for example, Sectigo, causing that specific SP to stop working. This can affect a lot of SPs on a single node (since the check is performed per node).

    When we look at the SAML 2.0 specification, there is no description of how, or even if, the certificate should be checked. In fact, it only concerns the public key. In my view, this check is entirely unnecessary.

    So, we have also chosen this solution. However, it is not ideal, because, as far as I understand, this applies to more than just the certificates used for federations.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.