Sorry, not yet. We don't have acces to the PLC 
managed by another firm.
I keep you updated as soon as we can run the test. I Hope before the freeze for the 8.1.38...
We run the test today.
The CA certificate is now accepted by Ignition with the change 
But, we have an issue about the CRL.
We place the file in:
client/security/pki/issuers/crl
The crl file seems to be ignored by Ignition ?
Is there any logger to see if the file is read and processed ?
What is the Ignition behaviour if the certificate used for the connection is not provided in the CRL.
Would it be possible to have a message log like "serial number not found" in CRL ?
If the serial number is found with a revocation date expired, Ignition disconnect the opc connection ?
(As a side note: the crl file we grab on site has only 3 days of validity, so we change the date of the server)
INFO | jvm 1 | 2024/01/24 15:01:05 | W [o.e.m.o.s.c.u.v.CertificateValidationUtil] [14:01:05]: Failed to add custom revocation checker; REVOCATION_LIST_FOUND check will be ignored.
We run some test with UaExpert
UaExpert seems to refuse to connect because the certificate is not found in the CRL file
Edit: full screenshot
I think UaExpert is failing because you don’t have 2 CRLs, one for each issuer.
The warning in Ignition is saying that the presence of a CRL file for each issuer cert is not being enforced.
I don’t know if I can add some logging or not. This stuff just calls into Java libraries pretty quickly.
That would be rather noisy, since unrevoked certs are not supposed to be in the file. Not being there is the "good" case.
Ok I see ! That's right.
You mean I need a CRL file for the CA and another file for the sub CA ?
Ignition is looking for 2 files too ?
No, Ignition is ultimately doesn't care if there are any, as the warning suggested.
UaExpert wants 2. Each CRL is tied to a certificate. Any certificate signing another certificate could/should have a CRL.
OK, But for Ignition how can I make the proof that the CRL file provided for the sub CA is taken in account ?
In my use case,
Failed to add custom revocation checker; REVOCATION_LIST_FOUND check will be ignored.
is relative to the crl missing for CA or the serial number of the certificat not found in CA_Subordinate01.crl ?
Do I need that my customer provide me a CRL file with the certificate used revocated in order that I can check Ignition disconnect the opc connection ?
Yes I suppose you might need to do that. There doesn't seem to be any logging and the revocation checking code is all part of the Java security libraries.
I'm not sure there's a lot of value in pursuing this... you don't have any mechanism in place to automatically update the CRLs in Ignition as far as I can see. In the future the PKI infrastructure is meant to be managed by an OPC UA GDS that is acting as a certificate/security manager, but that's not supported by Ignition at the moment, even if you had one.
I was supposed the crl file could be copied in Ignition crl directory and it will be evaluated ?
You mean the file is only evaluated when the opc client connection is connecting.
It gets decoded and loaded into memory when it's put in that directory, but nothing uses it until a certificate chain needs to be validated.
Ok thanks a lot for all these clarification.
As a workaround, do you think it could be possible to call some code from a gateway script using something like:
org.eclipse.milo.opcua.stack.core.util.validation.OpcUaCertificateRevocationChecker
to be able to trigger an alarm in Ignition if the certificate has been revoked ?
Probably not easy...but if we can have a script function exposed by the opcua module to periodically check the revocation of opcua certificate, we will be able to alert the user/administrator. Not perfect but better than nothing.
Do you know the ETA for 8.1.38 ?
We have to push it on site as soon as possible with this change.
Planned for March 5, 2024.
1 Like
@Kevin.Herron
Our customer try to renew an opcua certificat in the PLC and he has the following issue:
required KeyUsage 'nonRepudiation' not found
This a probably changed regarding the previous certificat, but I'm not sure this key is mandatory in opcua spec ? Ignition is perhaps too strict ?
sorry, I don't have better logs that this screenshot...
‘nonRepudiation’ is a required KeyUsage for application instance certificates.
It was never checked for issuer certs and the other unnecessary checks were removed entirely by CertificateValidationUtil issuer certificate KeyUsage checks · Issue #1206 · eclipse-milo/milo · GitHub