OPCUA certificate rejected with error: Bad_SecurityChecksFailed

mazeyrat · January 16, 2024, 9:48am

We can now run some tests with en DEV env.
In a first step, we keep opcua auto-signed ignition certificates.

We have put the CA files in:

Ignition\data\opcua\client\security\pki\issuers\certs

Same der files in:

Ignition\data\certificates\supplemental

was ignored despide gateway restart.

Now the CA seems to be found, but we have the error KeyUsage 'digitalSignature' not found

	[remote=/10.30.33.11:4840] Exception caught: UaException: status=Bad_SecurityChecksFailed, message=java.security.cert.CertPathValidatorException: required KeyUsage 'digitalSignature' not found

The CRL seems to be ignored:

Error fullstack trace:

io.netty.handler.codec.DecoderException: UaException: status=Bad_SecurityChecksFailed, message=java.security.cert.CertPathValidatorException: required KeyUsage 'digitalSignature' not found

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:499)

at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)

at io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)

at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientAcknowledgeHandler.decode(UascClientAcknowledgeHandler.java:171)

at io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)

at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)

at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290)

at io.netty.handler.codec.ByteToMessageCodec.channelRead(ByteToMessageCodec.java:103)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)

at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)

at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)

at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)

at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)

at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)

at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)

at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)

at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)

at java.base/java.lang.Thread.run(Unknown Source)

Caused by: org.eclipse.milo.opcua.stack.core.UaException: java.security.cert.CertPathValidatorException: required KeyUsage 'digitalSignature' not found

at org.eclipse.milo.opcua.stack.core.util.validation.CertificateValidationUtil.validateTrustedCertPath(CertificateValidationUtil.java:287)

at org.eclipse.milo.opcua.stack.client.security.DefaultClientCertificateValidator.validateCertificateChain(DefaultClientCertificateValidator.java:79)

at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientMessageHandler.onOpenSecureChannel(UascClientMessageHandler.java:469)

at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientMessageHandler.decodeMessage(UascClientMessageHandler.java:394)

at org.eclipse.milo.opcua.stack.client.transport.uasc.UascClientMessageHandler.decode(UascClientMessageHandler.java:382)

at io.netty.handler.codec.ByteToMessageCodec$1.decode(ByteToMessageCodec.java:42)

at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529)

at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468)

... 26 common frames omitted

Caused by: java.security.cert.CertPathValidatorException: required KeyUsage 'digitalSignature' not found

at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(Unknown Source)

at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown Source)

at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(Unknown Source)

at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(Unknown Source)

at java.base/java.security.cert.CertPathValidator.validate(Unknown Source)

at org.eclipse.milo.opcua.stack.core.util.validation.CertificateValidationUtil.validateTrustedCertPath(CertificateValidationUtil.java:249)

... 33 common frames omitted

Caused by: org.eclipse.milo.opcua.stack.core.UaException: required KeyUsage 'digitalSignature' not found

at org.eclipse.milo.opcua.stack.core.util.validation.CertificateValidationUtil.checkIssuerKeyUsage(CertificateValidationUtil.java:631)

at org.eclipse.milo.opcua.stack.core.util.validation.OpcUaCertificateUsageChecker.check(OpcUaCertificateUsageChecker.java:130)

... 39 common frames omitted

Perhaps there is something wrong with the field "Utilisation de la clé / usage de la key"
(certificate rejected in PM)

Another question, when this item will be solved, we would like to try to add CRL files.
If ignition doesn't use http url, we can download them an put it in the directory:

Ignition\data\opcua\client\security\pki\issuers\crl

but is there a name convention and a format expected for the file(s) ?

Kevin.Herron · January 16, 2024, 1:42pm

The end entity certificate you sent me has the digitalSignature KeyUsage, but maybe one of the issuers doesn't. Can you send the whole chain?

mazeyrat · January 16, 2024, 2:06pm

in the logger, we have the following certificateChai

certificateChain: [[ [ Version: V3 Subject: CN=46ORY-APBT-S71-S02v4-0001 Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits params: null modulus: 17503854889831707109148801732893930287825551772454250205274602359566779167883480963380827282254709954564513969536170564625061316874573879713537125998484055528127252147451567626184443492220245157006281950149812941348089212757390823677577228874688079433005953545972093457754376156129805362782059143563932835503789676842104622831788967472480790452153752527308350134771505725724457418856711589780590490925142236070435318982737212089686207914240828716035870517979414310218593557325628910291340081656341313341129121451505204890774159473332306839422298778516709732813462739953439368774075700488434898876090563642228032061263 public exponent: 65537 Validity: [From: Wed Jan 10 16:10:37 CET 2024, To: Fri Jan 10 16:10:37 CET 2025] Issuer: CN=CA_Subordinate01_GPE-L18, O=GPE-L18, C=FR SerialNumber: [ 73987306 4685b928 e1247468 52c345f0] Certificate Extensions: 7 [1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: ocsp accessLocation: URIName: http://gpe-l18-ocsp.gpe-l18.sgp:8085/basic ] ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 4A 6E 1D FC BC 7D C5 D4 Jn...... ] ] [3]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://gpe-l18-ocsp.gpe-l18.sgp/CRL/CA_Subordinate01.crl] ]] [4]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] [5]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment ] [6]: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: 46ORY-APBT-S71-S02v4-0001.gpe-l18.sgp URIName: urn:SIMATIC.S7-1500.OPC-UA.Application:API_ORY_P_1 DNSName: 46ORY-APBT-S71-S02v4-0001 IPAddress: 10.30.33.11 Other-Name: Unrecognized ObjectIdentifier: 1.3.6.1.4.1.311.20.2.3 ] [7]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 41 3B 9E 65 CA E8 0D 10 A;.e.... ] ] ] Algorithm: [SHA256withRSA] Signature: 0000: 14 0C 77 CB EB 98 57 13 E6 51 3E 1C EC 80 CD 17 ..w...W..Q>..... 0010: E6 C7 65 18 90 55 7D CB 30 D3 C9 AC 9B 14 EA 1B ..e..U..0....... 0020: B3 53 A2 CD F7 54 3D 7F 4E 18 23 96 B9 58 78 C3 .S...T=.N.#..Xx. 0030: E5 FE 7B 57 F9 6C 79 19 2B 28 1A D2 FB BE 1E CB ...W.ly.+(...... 0040: 0A C2 EE A1 43 83 11 03 D4 0F C4 81 FF B0 20 FA ....C......... . 0050: 44 36 04 DB A5 EA FA 4B 7A C2 38 D8 C5 5C F0 19 D6.....Kz.8..\.. 0060: 4E EC 3F 44 0D 33 7A 28 4A DD 70 57 BB 7E B0 DB N.?D.3z(J.pW.... 0070: 7C 8A 2D A6 C7 44 17 39 0F 34 02 01 96 75 C4 88 ..-..D.9.4...u.. 0080: C6 86 9F 02 E7 85 45 70 06 A7 9A 23 E0 A6 F7 63 ......Ep...#...c 0090: 0B 12 34 8F 6F 42 EE BD D3 14 E4 6E CA CC F2 30 ..4.oB.....n...0 00A0: 31 FF 70 F8 A1 23 E8 E7 0B 0E 64 94 B3 18 F6 AA 1.p..#....d..... 00B0: BF A4 9A 76 F9 88 D3 48 DD 27 88 0C EA F7 8E 8A ...v...H.'...... 00C0: F3 29 FE ED 65 C6 02 1A 39 04 CF 6B E8 5A 2F A6 .)..e...9..k.Z/. 00D0: DD 69 1B 89 03 95 90 01 B2 13 D8 66 44 22 7C E8 .i.........fD".. 00E0: 00 7A C8 E9 27 D3 3B 97 E5 21 40 14 94 8C CF 8F .z..'.;..!@..... 00F0: 2D 59 F8 0C 1A C5 96 45 13 8D 56 77 86 5D E0 8D -Y.....E..Vw.].. 0100: B2 B1 D5 C0 BA 8E FF 38 64 AF 80 72 99 4F FC 62 .......8d..r.O.b 0110: 43 62 C4 70 5A 25 47 11 22 35 20 90 9E B5 97 2C Cb.pZ%G."5 ...., 0120: CE 6E 79 1A C5 1F ED BC 83 A9 1A F6 13 32 BB C2 .ny..........2.. 0130: 03 05 C5 D5 AA 25 E1 70 7E BB 88 47 61 A1 DF CA .....%.p...Ga... 0140: 1C 93 45 AF A9 71 CF 30 08 8A FD CD 4A 62 EB 91 ..E..q.0....Jb.. 0150: 5B 8A EE 06 08 1D BD 7A F5 32 ED 40 CF 64 7E 24 [......z.2.@.d.$ 0160: A8 CC CB 11 60 51 F7 0F EA 45 D4 6F C4 B3 6F 4B ....`Q...E.o..oK 0170: 25 EE 3B 28 5F AF 08 57 E6 3A 0A A2 25 B2 6F E8 %.;(_..W.:..%.o. 0180: 94 C1 6C AB 2C A2 22 93 CA 97 83 D7 A9 32 65 91 ..l.,."......2e. 0190: 54 19 AD 72 EB 5C 4A 7B F3 60 BA 9E 20 3B EF 62 T..r.\J..`.. ;.b 01A0: 99 B1 7F EB 41 83 B5 20 10 A5 B3 BA F1 B1 B1 65 ....A.. .......e 01B0: DA B9 FD EC 90 8A 8C 71 E3 F2 71 5E ED 44 E7 A7 .......q..q^.D.. 01C0: B9 2F 3B C2 8D 94 55 54 EC BF 23 C2 E2 B4 E3 C7 ./;...UT..#..... 01D0: A0 D9 51 D7 E0 8C 8F BF 02 38 D7 D2 28 00 E9 ED ..Q......8..(... 01E0: E7 79 8B 73 9D AF 9C 38 C0 97 F3 E4 29 4A 72 51 .y.s...8....)JrQ 01F0: 80 73 6E 49 3A E2 2A 51 28 49 45 9B 22 3D 0D 60 .snI:.*Q(IE."=.` ]]

Kevin.Herron · January 16, 2024, 2:07pm

I mean send me all the certificate files

mazeyrat · January 16, 2024, 2:13pm

ok,
I've send you 2 more files by PM:

ca_root.der
ca_sub01.der

Kevin.Herron · January 16, 2024, 2:19pm

Ok, it seems that the issuer does not have Digital Signature indicated in its Key Usage and the certificate validation logic is expecting it to be there.

Looking closer at the spec it seems this may be a mistaken requirement of issuer certs, and is only required of the end entity (application instance) certificate, but I'll have to reach out to someone for verification.

There's nothing you can do to get this working unless re-generating those root and issuer certificates to include the missing Key Usage is a possibility. You might be able to get a connection to happen if you disable certificate validation all together for that connection (advanced setting).

mazeyrat · January 16, 2024, 3:12pm

Thanks a lot, I stay tuned if there is something wrong regarding the spec in the certificate

mazeyrat · January 17, 2024, 8:58am

According to:

https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2.2#_Ref183310394

For RSA keys, the keyUsage shall include digitalSignature, nonRepudiation, keyEncipherment and dataEncipherment.For ECC keys, the keyUsage shall include digitalSignature.Other keyUsage bits are allowed but not recommended.

Do you have a feedback about keyUsage ?

Kevin.Herron · January 17, 2024, 1:21pm

What you linked are requirements for the application instance (end entity) certificate.

I think they are much less for the issuers: UA Part 6: Mappings - 6.2.4 Issuer (CA) Certificates

mazeyrat · January 22, 2024, 9:31pm

Hi Kevin,

I just see you had make a change/fix relative to certificate validation:

github.com/eclipse/milo

CertificateValidationUtil issuer certificate KeyUsage checks

opened 05:51PM - 20 Jan 24 UTC

closed 08:18PM - 22 Jan 24 UTC

kevinherron

bug interop stack

`CertificateValidationUtil` is enforcing that issuer/CA certs have certain KeyUs…age attributes (`digitalSignature`, `keyCertSign`, `cRLSign`), but this is not actually required by the spec: https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2.4 Consequently, we're unable to connect with other OPC UA applications using a certificate chain containing issuers/CA certs missing these attributes. These checks should be removed.

This could help us perhaps to solve our issue ?
We will run some test tuesday and wednesday this week on our test env.

Would it be possible to send me a beta version of the opcua module with milo 0.6.12-beta with this change/fix ?

Thanks
Lionel

Kevin.Herron · January 22, 2024, 9:38pm

I should be able to send you one by tomorrow, however it may not work unless you are on a nightly gateway release as well.

mazeyrat · January 22, 2024, 10:12pm

That's great

Kevin.Herron · January 24, 2024, 6:05pm

@mazeyrat here's that module. As I mentioned, you'll need to install it into a nightly release of Ignition.

mazeyrat · January 24, 2024, 7:52pm

Thanks a lot, I've upgraded my Ignition plateform with the last nightly available and the opcua module posted. I will keep you updated as soon as the PLC will be available tu run some test again.

mazeyrat · January 26, 2024, 4:30pm

We are still waiting for the availability of the PLC to valid the new OPC-UA-module version.

The next question, is how do you process the CRL ?

[DistributionPoint: [URIName: http://gpe-l18-ocsp.gpe-l18.sgp/CRL/CA_Subordinate01.crl]

If Ignition doesn't request automatically the http Uri name, can we put the file anywhere on the gateway in order it will be take in account ? is there a name convention ?

For example we can perhaps disable/enable the opc connection to force a new crl file to be processed ?

I send you by PM the CRL file provided by the http uri name.

Kevin.Herron · January 26, 2024, 4:33pm

You can just put it in the client/security/pki/issuers/crls folder, in der-encoded PKCS#7 format. The filename doesn't matter, any CRLs in that dir get read and included.

mazeyrat · January 26, 2024, 4:36pm

ok, is the format of the file provided by PM OK ?

client/security/pki/issuers/crls is scaned periodically ? how often ?

Kevin.Herron · January 26, 2024, 4:37pm

Looks like it's already the right format. The directory is watched by a Java file watch service, it should get noticed more or less immediately.

mazeyrat · January 26, 2024, 4:39pm

Great, I will test as soon as possible !

Kevin.Herron · January 30, 2024, 5:48pm

Did you get a chance to test this?