Connection refused if T field exists in X509 credentials

[n-deliyski]

If an MQTT device is registered manually with X.509-cert credentials, where the certificate subject-DN has T field (e.g T=Test), the device connection is refused with "Bad username or password". This is not expected as title is valid attribute type - rfc4519

The device certificate is created via command: openssl req -key <device-key.pem> -new -out <device.csr> -subj "/title=Test/CN=..."

The analysis shows following:

1. During device manual provisioning the auth-id is normalized using call to new X500Principal(<auth-id-string>).getName(X500Principal.RFC2253). This call for T=Test gives OIDs mapping 2.5.4.12=#130454657374, where 0x13 is for PrintableString
2. During device connection the auth-id is retrieved from the certificate provided by the device using Certificate#getSubjectX500Principal().getName(X500Principal.RFC2253)
   See https://github.com/eclipse-hono/hono/blob/master/adapter-base/src/main/java/org/eclipse/hono/adapter/auth/device/x509/TenantServiceBasedX509Authentication.java#L170. This call gives 2.5.4.12=#0c0454657374, where 0x0c is for UTF8String
3. Inside the binary certificate the field value is 0c0454657374, where 0x0c is for UTF8String.
4. During connection attempt the auth-id 2.5.4.12=#0c0454657374 could not be found, thus the connection is refused.

This behavior seems a rear case only if the subject-DN has non standard rfc2253 fields.

[sophokles73]

Did you use the same certificate that the client device uses also for registering the device?

[n-deliyski]

During device registration the certificate was not provided. The credentials API was called passing auth-id as T=Test,CN=...

[sophokles73]

You mean the Device Registry Management API's update Credentials operation had been used to add X.509 credentials passing a public key and the auth-id explicitly instead of specifying a certificate?

[n-deliyski]

Yes, Device Registry Management API's update Credentials operation had been used.
The request body had contained only type=x509-cert and auth-id=T... (no public key).

[sophokles73]

Can you check if the the same problem occurs when you provide the device's client cert when registering the X.509 credentials?

[n-deliyski]

I have tested that.
If the device's client cert is provided into the body, the auth-id is created properly and the device could connect.
The created auth-id is 2.5.4.12=#0c0454657374,CN=...
So, no problem using that way of adding credentials.
For completeness here is an example of the request:

curl -X 'PUT'
'http://localhost:8080/credentials/<tenant-id>/<device-id>'
-H 'accept: */*'
-H 'Content-Type: application/json'
-H 'Authorization: Basic .....'
-d '[
{
"type": "x509-cert",
"secrets": [
{
}
],
"cert": "<Base64 encoded DER binary of device certificate>"
}
]'

[sophokles73]

That's what I thought. FMPOV there is no bug here. However, it would be good to better understand under what circumstances the value of title attribute is being interpreted as a PrintableString vs UTF8String ...

[n-deliyski]

This issue was reported by a client.
After finding out the issue with title, they decided to not use title into the subject-DN.
At their use case there is no possibility to provide the device's client cert when registering the X.509 credentials.

If the PrintableString or UTF8String interpretation is clear and eventually documented, the advice to them could be to register providing the proper OIDs mapped value.

[sophokles73]

@n-deliyski is this still an issue?