I've dropped in to an environment where auditing is not working. No history. Not sure how we got here from wherever it was last working. Sentinel is 7.4, and there's a Collector Manager that the agents are talking to. The CM was 7.4, last updated July 2016, as far as I can tell. I saw in the log file for the collector that it was trying / failing to communicate using SSLv2 ("xxx.xxx.xxx.xxx:55549: Error encountered in sendClient(1): javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled"), and found a few references to upgrading to current version to make it stop doing that. Made sense. So I did a "zypper up", so now it's current, at 8.1?

I'm no longer getting the SSLv2 errors, so that seems to have worked. But now I'm stuck with "Certificates does not conform to algorithm constraints" errors. They look a lot like:

        /xxx.xxx.xxx.xxx:58322: Error encountered in sendClient(1): javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
Thu Jul 06 17:30:07 EDT 2017|SEVERE|Thread-1298|esecurity.ccs.comp.evtsrcmgt.connector.auditserver.DeviceSensorAuditListener$LEngine.sendClient

        Root cause: Certificates does not conform to algorithm constraints (java.security.cert.CertificateException)
        javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
                at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
                at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
                at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
                at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
                at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1906)
                at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:233)
                at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
                at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
                at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
                at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
                at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
                at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
                at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)
                at java.io.DataOutputStream.write(DataOutputStream.java:88)
                at esecurity.ccs.comp.evtsrcmgt.connector.auditserver.DeviceSensorAuditListener$LEngine.sendClient(DeviceSensorAuditListener.java:949)
                at esecurity.ccs.comp.evtsrcmgt.connector.auditserver.DeviceSensorAuditListener$LEngine.handle_LE_CMD_STARTTLS(DeviceSensorAuditListener.java:666)
                at esecurity.ccs.comp.evtsrcmgt.connector.auditserver.DeviceSensorAuditListener$LEngine.performHandShake(DeviceSensorAuditListener.java:607)
                at esecurity.ccs.comp.evtsrcmgt.connector.auditserver.DeviceSensorAuditListener$LEngine.run(DeviceSensorAuditListener.java:462)
        Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
                at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1117)
                at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1043)
                at sun.security.ssl.AbstractTrustManagerWrapper.checkClientTrusted(SSLContextImpl.java:978)
                at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1888)
                ... 13 more
I found several references to changing java.security to allow for old/broken algorythms (jdk.certpath.disabledAlgorithms=MD2). I've tried that, it doesn't help.

Digging in deeper, I think I see what's going on, but I'm not sure. I found references to needing to update the platform agent(s). I think I see why, too. Looking in the cache directory, there are some ugly named files. Those are the platform agent cache. If you look in them, you'll see that they contain an embedded certificate. In my case, I have two cache files, both with embedded certs that expired in 2013. After upgrading the eDir instrumentation (novell-AUDTedirinst- and platform agent (novelplatformagent-2.0.2-77), I have a new one with an embedded certificate that expires in 2024. My conclusion is that the upgraded PA uses a newer cert. Interestingly, even the new one has a 1024 bit key size.

But, over on the collector manager, I'm still seeing the certificate validation error above. I think that it may be because the PA is busy trying to send data that has the old cert in it. I haven't been able to find a way to get the CM to accept this and move on with life. I don't really want to lose audit data if I can help it here. Is there a way to configure Java on the CM to accept expired certificates?