We should not check hostname/ipaddress for "domain-issued certificate" · Issue #1052 · eclipse-leshan/leshan · GitHub
More Web Proxy on the site http://driver.im/
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
Here is how this certificate usage is defined by rfc6698 :
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.And this is the case for default
Domain-issued ceritficate
usage.(bug revealed by #1050)
The text was updated successfully, but these errors were encountered: