GXx509Cetrificate class error

By VitalyP , 25 February, 2021

Forums

Hello,

I found, that certificates, generated by https://certificates.gurux.fi/api/CertificateGenerator gives different KeyUsage interpretation related to other Certificate parsers.
For example, CertificateGenerator give me following certificate:

Gurux.DLMS library shows, that KeyUsage for this certificate is DigitalSignature. But, if you will parse this certificate in other parsers (such as OpelSSl or https://redkestrel.co.uk/products/decoder/), KeyUsage for this certificate is EnchiperOnly.

And vice versa - CErifficetes, generated by OpenSSL with DigitalSignature key usage, Gurux.DLMS shows as EnchiperOnly.

So, I think, that Gurux.DLMS shows wrong representation of KeyUsage parameter.

Rerards,
Vitaly

Hi,

Thank you for this information and you are right. KeyUsage is a bitstring and not the enum. This causes that the first value is the Least Significant Bit and not the Most Significant Bit. The enum values are now reversed. This is fixed and the new version is released latest tomorrow.

BR,
Mikko

Also, I want to say, that

Also, I want to say, that your approach for GXx509Certificate class is not good.
There are some potential problem.
On loading certificates, they immediately deserialized into class fields. As soon as you need to use byte array ASN1 representation of certificate, class serializes fields back to Encoded byte array.
But, in some cases serialized Encoded byte array can be differ from the original certificate byte array representation.
This is because, for example, bitstring fields may have different representation for the same value.
Or, some fields can be grouped in different orders.
But, certificate includes the digital signature for it's byte array representation. If Encoded byte array will be differ from original one, signature verification will fail.
So, in my opinion, better approach for the class is to keep Encoded byte array inside class.
Or you need to find solution to guarantee, that serialized representation will always exactly match the original one

Hi,

Thanks for the good points. We can also save a few bytes if save is removed. That is critical with ANSI C.
I need to think about this.

BR,
Mikko

Hi,

I still can't add valid certificate to GuruxGXDLMSDirector.

This certificate successfully parsed in openSSL as:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
ca:5e:fa:d6:73:7e:52:54
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=ENERGOMERA-CA
Validity
Not Before: Mar 11 14:37:17 2021 GMT
Not After : Mar 11 14:37:17 2022 GMT
Subject: CN=454D520700000001
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:b2:db:54:75:f8:07:69:23:7d:be:d4:5f:be:0d:
0e:ce:d5:b0:4a:c7:28:99:39:9c:98:d9:c5:44:64:
50:de:74:dc:29:ae:f1:d8:68:f3:58:ad:0c:29:cb:
e5:97:f0:78:05:ce:ad:78:6a:6c:26:ac:87:eb:34:
70:c8:20:bb:86
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:AC:EB:34:A3:E2:C1:8D:70:27:E7:56:07:1E:04:F9:15:5D:0D:AC:1D

X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:5b:13:e8:62:5b:45:2d:a1:c6:5b:65:f6:d6:ab:
f0:85:c3:a7:24:54:5c:90:00:6f:c1:c7:88:08:db:65:e2:4c:
02:20:43:a2:5b:5e:2d:03:d2:9d:3a:b6:f0:e3:0d:47:b3:6e:
5d:5c:8f:dc:16:73:90:36:f0:7d:22:ce:ee:90:52:6b

So, this certificate has all fields, defined in DLMS greenbook,
But if I try to load it in DLMA library, it throw exception.

Probably library doesn't handle "X509v3 Authority Key Identifier" correctly.

regatds,
Vitaly

Forum Rules

Hi,

Also, I want to say, that

Hi,

Hi,

Hi,

Hi,

Hi Vitaly,

Hi,