8000 We should not check hostname/ipaddress for "domain-issued certificate" · Issue #1052 · eclipse-leshan/leshan · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

We should not check hostname/ipaddress for "domain-issued certificate" #1052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sbernard31 opened this issue Jul 15, 2021 · 1 comment
Closed
Labels
bug Dysfunctionnal behavior client Impact LWM2M client

Comments

@sbernard31
Copy link
Contributor
sbernard31 commented Jul 15, 2021

Here is how this certificate usage is defined by rfc6698 :

3 -- Certificate usage 3 is used to specify a certificate, or the
public key of such a certificate, that MUST match the end entity
certificate given by the server in TLS. This certificate usage is
sometimes referred to as "domain-issued certificate" because it
allows for a domain name administrator to issue certificates for a
domain without involving a third-party CA. The target certificate
MUST match the TLSA record. The difference between certificate
usage 1 and certificate usage 3 is that certificate usage 1
requires that the certificate pass PKIX validation, but PKIX
validation is not tested for certificate usage 3.

Since commit 6e96cee, we check that server domaine name match certificate subject (CN or SAN).

(see : 6e96cee#diff-931a77d08ccaac2b0e41df0ff579c5a92d835591a38275ab0d262dafdf3d40a1R101-R115)

But reading the LWM2M spec v1.1, it seems this check must not be done if Server Certificate match exactly Certificate available in Server Public Key Resource.

Comparing the reference identifier against the presented identifier obtained from the certificate is required to ensure the TLS/DTLS client is communicating with the intended TLS/DTLS server. To cater for the case that the Server Public Key Resource directly contains the certificate of the TLS/DTLS server, TLS/DTLS client does not compare the reference identifier against the presented identifier if the certificate from the Server Public Key Resource matches the certificate provided by the TLS/DTLS server during the TLS/DTLS handshake. If that is not the case, the TLS/DTLS client MUST compare the reference identifier against the presented identifier as described below, and perform path validation.

And this is the case for default Domain-issued ceritficate usage.

(bug revealed by #1050)

@sbernard31
Copy link
Contributor Author

It should be fixed by 83a3f2b

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Dysfunctionnal behavior client Impact LWM2M client
Projects
None yet
Development

No branches or pull requests

1 participant
0