Discussion:
httpcomponents-client 4.5.3 - Certificate doesn't match any of the subject alternative names
Andy Signer
2018-02-20 21:51:03 UTC
Permalink
Hi everyone,

Last week I ran into certificate verification error with
httpcomponents-client 4.5.3. A certificate was rejected with the
following message:

javax.net.ssl.SSLPeerUnverifiedException: Certificate for
<www.company.com> doesn't match any of the subject alternative names:
[***@example.com]

After some investigation I found that the certificate was rejected
because the commonName is ignored when there is a subjectAltName entry
present (see [HTTPCLIENT-1802]). The certificate is a bit special
because there is just one email address in the subjectAltName, nothing
else.

I read parts of [rfc5280] and [rfc6125] and tried to figure out (I
failed) if the presented certificate is invalid and should be rejected
(as happens) or if the email address in the subjectAltName is just
additional information which can be ignored by the
DefaultHostnameVerifier and the verification should fallback to the
commonName.

What do you think? Should I just ask the owner of the certificate to
change it or is there something which could be improved in the default
hostname verification?

Best regards
Andy Signer

PS: A unit test to demonstrate the rejected certificate
https://github.com/asigner/httpcomponents-client/pull/1

References
[rfc5280] https://tools.ietf.org/html/rfc5280#section-4.2.1.6
[rfc6125] https://tools.ietf.org/html/rfc6125#section-6.4.4
[HTTPCLIENT-1802] https://issues.apache.org/jira/browse/HTTPCLIENT-1802

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Oleg Kalnichevski
2018-02-21 10:37:24 UTC
Permalink
Post by Andy Signer
Hi everyone,
Last week I ran into certificate verification error with
httpcomponents-client 4.5.3. A certificate was rejected with the
javax.net.ssl.SSLPeerUnverifiedException: Certificate for
After some investigation I found that the certificate was rejected
because the commonName is ignored when there is a subjectAltName entry
present (see [HTTPCLIENT-1802]). The certificate is a bit special
because there is just one email address in the subjectAltName,
nothing
else.
HttpClient (both 4.x and 5.x) has been revised for compliance with RFC
2818 only. RFC 2818 is pretty clear about host name verification based
on certificate Common Name attribute being deprecated.


RFC 2818

---

3.1.  Server Identity
...

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
---

What I would like to see is whether or not the subjectAltName attribute
in the certificate has been declared as email address. If the
attribute type declares the entry as DNS or IP, then the certificate is
clearly invalid.

Oleg
Post by Andy Signer
I read parts of [rfc5280] and [rfc6125] and tried to figure out (I
failed) if the presented certificate is invalid and should be
rejected
(as happens) or if the email address in the subjectAltName is just
additional information which can be ignored by the
DefaultHostnameVerifier and the verification should fallback to the
commonName.
What do you think? Should I just ask the owner of the certificate to
change it or is there something which could be improved in the
default
hostname verification?
Best regards
Andy Signer
PS: A unit test to demonstrate the rejected certificate
https://github.com/asigner/httpcomponents-client/pull/1
References
[rfc5280] https://tools.ietf.org/html/rfc5280#section-4.2.1.6
[rfc6125] https://tools.ietf.org/html/rfc6125#section-6.4.4
[HTTPCLIENT-1802] https://issues.apache.org/jira/browse/HTTPCLIENT-18
02
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Andy Signer
2018-02-21 16:14:49 UTC
Permalink
Hi Oleg,

Thank you for your clarification. If I understood correctly the Common
Name attribute is deprecated but still in use. The
DefaultHostnameVerifier is using it as a fallback if there is no
subjectAltName entry.
Post by Oleg Kalnichevski
What I would like to see is whether or not the subjectAltName attribute
in the certificate has been declared as email address. If the
attribute type declares the entry as DNS or IP, then the certificate is
clearly invalid.
Here an example certificate which reflects the certificate I had
issues with. It just contains one email address in subjectAltName,
neither a DNS nor an IP entry.

-----BEGIN CERTIFICATE-----
MIIDpTCCAo2gAwIBAgIJANqkMEtlkelbMA0GCSqGSIb3DQEBCwUAMHAxCzAJBgNV
BAYTAlVTMQswCQYDVQQIDAJWQTERMA8GA1UEBwwIU29tZUNpdHkxEjAQBgNVBAoM
CU15Q29tcGFueTETMBEGA1UECwwKTXlEaXZpc2lvbjEYMBYGA1UEAwwPd3d3LmNv
bXBhbnkuY29tMB4XDTE4MDIxNTA3MjkzMFoXDTIwMDIxNTA3MjkzMFowcDELMAkG
A1UEBhMCVVMxCzAJBgNVBAgMAlZBMREwDwYDVQQHDAhTb21lQ2l0eTESMBAGA1UE
CgwJTXlDb21wYW55MRMwEQYDVQQLDApNeURpdmlzaW9uMRgwFgYDVQQDDA93d3cu
Y29tcGFueS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4v6Oq
Ua0goRVn1cmT7MOpJhXFm3A70bTpvJIRpEjtGIz99hb34/9r5AYyf1VhKyWmBq24
XNcOJ59XOlyjjbm2Tl811ufTOdcNbPadoVBmMt4039OSUFpVb4wAw2XPWLTCG2h1
HNj9GuFHmwcDsg5EiIRrhDGQm2LLLAGoe5PdReoMZCeeWzNWvKTCV14pyRzwQhJL
F1OmzLYzovbPfB8LZVhQgDbLsh034FScivf2oKDB+NEzAEagNpnrFR0MFLWGYsu1
nWD5RiZi78HFGiibmhH7QrEPfGlo2eofuUga6naoBUROqkmMCIL8n1HZ/Ur0oGny
vQCj1AyrfOhuVC53AgMBAAGjQjBAMAsGA1UdDwQEAwIEMDATBgNVHSUEDDAKBggr
BgEFBQcDATAcBgNVHREEFTATgRFlbWFpbEBleGFtcGxlLmNvbTANBgkqhkiG9w0B
AQsFAAOCAQEAZ0IsqRrsEmJ6Fa9Yo6PQtrKJrejN2TTDddVgyLQdokzWh/25JFad
NCMYPH5KjTUyKf96hJDlDayjbKk1PMMhSZMU5OG9NOuGMH/dQttruG1ojse7KIKg
yHDQrfq5Exxgfa7CMHRKAoTCY7JZhSLyVbTMVhmGfuUDad/RA86ZisXycp0ZmS97
qDkAmzFL0sL0ZUWNNUh4ZUWvCUZwiuN08z70NjGqXMTDCf68p3SYxbII0xTfScgf
aQ/A/hD7IbGGTexeoTwpEj01DNvefbQV6//neo32/R5XD0D5jn3TCgZcMThA6H3a
VkEghVg+s7uMfL/UEebOBQWXQJ/uVoknMA==
-----END CERTIFICATE-----

Could this be valid?

I definitely ask the owner of the certificate to create a new
certificate containing DNS entries in the subjectAltName.

Best regards
Andy Signer

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Oleg Kalnichevski
2018-02-22 10:20:23 UTC
Permalink
Post by Andy Signer
Hi Oleg,
Thank you for your clarification. If I understood correctly the Common
Name attribute is deprecated but still in use. The
DefaultHostnameVerifier is using it as a fallback if there is no
subjectAltName entry.
Post by Oleg Kalnichevski
What I would like to see is whether or not the subjectAltName attribute
 in the certificate has been declared as email address. If the
attribute type declares the entry as DNS or IP, then the
certificate is
clearly invalid.
Here an example certificate which reflects the certificate I had
issues with. It just contains one email  address in subjectAltName,
neither a DNS nor an IP entry.
-----BEGIN CERTIFICATE-----
MIIDpTCCAo2gAwIBAgIJANqkMEtlkelbMA0GCSqGSIb3DQEBCwUAMHAxCzAJBgNV
BAYTAlVTMQswCQYDVQQIDAJWQTERMA8GA1UEBwwIU29tZUNpdHkxEjAQBgNVBAoM
CU15Q29tcGFueTETMBEGA1UECwwKTXlEaXZpc2lvbjEYMBYGA1UEAwwPd3d3LmNv
bXBhbnkuY29tMB4XDTE4MDIxNTA3MjkzMFoXDTIwMDIxNTA3MjkzMFowcDELMAkG
A1UEBhMCVVMxCzAJBgNVBAgMAlZBMREwDwYDVQQHDAhTb21lQ2l0eTESMBAGA1UE
CgwJTXlDb21wYW55MRMwEQYDVQQLDApNeURpdmlzaW9uMRgwFgYDVQQDDA93d3cu
Y29tcGFueS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4v6Oq
Ua0goRVn1cmT7MOpJhXFm3A70bTpvJIRpEjtGIz99hb34/9r5AYyf1VhKyWmBq24
XNcOJ59XOlyjjbm2Tl811ufTOdcNbPadoVBmMt4039OSUFpVb4wAw2XPWLTCG2h1
HNj9GuFHmwcDsg5EiIRrhDGQm2LLLAGoe5PdReoMZCeeWzNWvKTCV14pyRzwQhJL
F1OmzLYzovbPfB8LZVhQgDbLsh034FScivf2oKDB+NEzAEagNpnrFR0MFLWGYsu1
nWD5RiZi78HFGiibmhH7QrEPfGlo2eofuUga6naoBUROqkmMCIL8n1HZ/Ur0oGny
vQCj1AyrfOhuVC53AgMBAAGjQjBAMAsGA1UdDwQEAwIEMDATBgNVHSUEDDAKBggr
BgEFBQcDATAcBgNVHREEFTATgRFlbWFpbEBleGFtcGxlLmNvbTANBgkqhkiG9w0B
AQsFAAOCAQEAZ0IsqRrsEmJ6Fa9Yo6PQtrKJrejN2TTDddVgyLQdokzWh/25JFad
NCMYPH5KjTUyKf96hJDlDayjbKk1PMMhSZMU5OG9NOuGMH/dQttruG1ojse7KIKg
yHDQrfq5Exxgfa7CMHRKAoTCY7JZhSLyVbTMVhmGfuUDad/RA86ZisXycp0ZmS97
qDkAmzFL0sL0ZUWNNUh4ZUWvCUZwiuN08z70NjGqXMTDCf68p3SYxbII0xTfScgf
aQ/A/hD7IbGGTexeoTwpEj01DNvefbQV6//neo32/R5XD0D5jn3TCgZcMThA6H3a
VkEghVg+s7uMfL/UEebOBQWXQJ/uVoknMA==
-----END CERTIFICATE-----
Could this be valid?
I definitely ask the owner of the certificate to create a new
certificate containing DNS entries in the subjectAltName.
Hi Andy

The cert looks perfectly valid. The email address in question has been
correctly declared as rfc822Name.

HttpClient should fall back onto CN for hostname verification instead
of rejecting the certificate as invalid.

Please raise a JIRA for this defect.

Oleg

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Andy Signer
2018-02-22 21:29:43 UTC
Permalink
Hi Oleg,

I raised https://issues.apache.org/jira/browse/HTTPCLIENT-1906 for this issue.

Thanks a lot for your help!

Bests
Andy

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-***@hc.apache.org
For additional commands, e-mail: httpclient-users-***@hc.apache.org
Loading...