OpenSSL: Accept certificates marked for both server and client use

Message ID alpine.DEB.2.02.1402150018560.43540@department-of-alchemy.MIT.EDU
State Superseded
Headers show

Commit Message

Anders Kaseorg Feb. 15, 2014, 5:21 a.m.
Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in
forbidding certificates marked for client use.  For example, this
broke the MIT SECURE wireless network.  The extended key usage is a
_list_ of allowed uses, and rather than checking that client use is
not in the list, we should check that server use is in the list.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
 src/crypto/tls.h         |  2 +-
 src/crypto/tls_openssl.c | 10 ++++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

Comments

Jouni Malinen Feb. 15, 2014, 7:48 a.m. | #1
On Sat, Feb 15, 2014 at 12:21:32AM -0500, Anders Kaseorg wrote:
> Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in
> forbidding certificates marked for client use.  For example, this
> broke the MIT SECURE wireless network.  The extended key usage is a
> _list_ of allowed uses, and rather than checking that client use is
> not in the list, we should check that server use is in the list.

This is unfortunate.. This check was added based on an explicit
specification requirement on the server certificate being rejected if
it contains id-kp-clientAuth and as such, that commit was actually
following that requirement on purpose in the way that would trigger
based on any entry matching.

I understand the view that this should not break (reasonably) deployed
existing networks and this may require some reconsideration. However, I
don't think that this change to require id-kp-serverAuth to be present
would be good either since it would likely break even more use cases. It
might be more reasonable to reject the server based on id-kp-clientAuth
being present without id-kp-serverAuth.

Would it be possible to get the MIT SECURE server certificate that hits
this new constraint on id-kp-clientAuth being present? This would be
useful for further discussion on possible spec changes/clarifications.
Anders Kaseorg Feb. 15, 2014, 10:24 a.m. | #2
On 02/15/2014 02:48 AM, Jouni Malinen wrote:
> On Sat, Feb 15, 2014 at 12:21:32AM -0500, Anders Kaseorg wrote:
>> Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in
>> forbidding certificates marked for client use.  For example, this
>> broke the MIT SECURE wireless network.  The extended key usage is a
>> _list_ of allowed uses, and rather than checking that client use is
>> not in the list, we should check that server use is in the list.
>
> This is unfortunate.. This check was added based on an explicit
> specification requirement on the server certificate being rejected if
> it contains id-kp-clientAuth and as such, that commit was actually
> following that requirement on purpose in the way that would trigger
> based on any entry matching.

I’m not seeing that specification requirement.  I looked at EAP-TLS (RFC 
5216):

    Implementations SHOULD use the Extended Key
    Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
    at least one of the following is true:

    1) The certificate issuer included no Extended Key Usage identifiers
       in the certificate.
    2) The issuer included the anyExtendedKeyUsage identifier in the
       certificate (see Section 4.2.1.13 of [RFC3280]).
    3) The issuer included the id-kp-serverAuth identifier in the
       certificate (see Section 4.2.1.13 [RFC3280]).

and EAP-TTLS (RFC 5281):

    Clients and servers should implement policies related to the Extended
    Key Usage (EKU) extension [RFC5280] of certificates it receives, to
    ensure that the other party's certificate usage conforms to the
    certificate's purpose.  Typically, a client EKU, when present, would
    be expected to include id-kp-clientAuth; a server EKU, when present,
    would be expected to include id-kp-serverAuth.  Note that absence of
    the EKU extension or a value of anyExtendedKeyUsage implies absence
    of constraint on the certificate's purpose.

and the specification of id-ce-extKeyUsage itself (RFC 5280):

    If the extension is present, then the certificate MUST only be used
    for one of the purposes indicated.  If multiple purposes are
    indicated the application need not recognize all purposes indicated,
    as long as the intended purpose is present.  Certificate using
    applications MAY require that the extended key usage extension be
    present and that a particular purpose be indicated in order for the
    certificate to be acceptable to that application.

    If a CA includes extended key usages to satisfy such applications,
    but does not wish to restrict usages of the key, the CA can include
    the special KeyPurposeId anyExtendedKeyUsage in addition to the
    particular key purposes required by the applications.  Conforming CAs
    SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
    KeyPurposeId is present.  Applications that require the presence of a
    particular purpose MAY reject certificates that include the
    anyExtendedKeyUsage OID but not the particular OID expected for the
    application.

This is all about requiring certain key usage values to be included; 
there’s nothing about requiring other values to be excluded.

Admittedly, I should fix the patch to accept anyExtendedKeyUsage 
(XKU_ANYEKU) as well.

> I understand the view that this should not break (reasonably) deployed
> existing networks and this may require some reconsideration. However, I
> don't think that this change to require id-kp-serverAuth to be present
> would be good either since it would likely break even more use cases. It
> might be more reasonable to reject the server based on id-kp-clientAuth
> being present without id-kp-serverAuth.

We don’t reject if the EKU extension is missing entirely, and my patch 
doesn’t change that.  Are you worried about certificates that explicitly 
include an EKU extension listing none of id-kp-clientAuth, 
id-kp-serverAuth, or anyExtendedKeyUsage?

> Would it be possible to get the MIT SECURE server certificate that hits
> this new constraint on id-kp-clientAuth being present? This would be
> useful for further discussion on possible spec changes/clarifications.

Can I extract it from wpa_supplicant?  (I don’t have any kind of special 
access to the servers.  All that MIT provides is these fingerprints: 
http://kb.mit.edu/confluence/x/YgAwB .)

Anders
Jouni Malinen Feb. 15, 2014, 11:11 a.m. | #3
On Sat, Feb 15, 2014 at 05:24:38AM -0500, Anders Kaseorg wrote:
> I’m not seeing that specification requirement.  I looked at EAP-TLS
> (RFC 5216):

> This is all about requiring certain key usage values to be included;
> there’s nothing about requiring other values to be excluded.

I know. I was referring to a different specification (sorry, cannot talk
about details yet).

> We don’t reject if the EKU extension is missing entirely, and my
> patch doesn’t change that.  Are you worried about certificates that
> explicitly include an EKU extension listing none of
> id-kp-clientAuth, id-kp-serverAuth, or anyExtendedKeyUsage?

To be honest, I did not notice that, but I was thinking of not including
id-kp-serverAuth and now that you say it, I guess that could also happen
with an EKU (for something completely different) being included. I don't
think id-kp-serverAuth is universally used, so I don't really want to
mandate it. id-kp-clientAuth alone is actually already rejected by
OpenSSL, so no need for that separately in tls_openssl.c.

> >Would it be possible to get the MIT SECURE server certificate that hits
> >this new constraint on id-kp-clientAuth being present? This would be
> >useful for further discussion on possible spec changes/clarifications.
> 
> Can I extract it from wpa_supplicant?  (I don’t have any kind of
> special access to the servers.  All that MIT provides is these
> fingerprints: http://kb.mit.edu/confluence/x/YgAwB .)

You can extract the server certificate with a connection to probe for
such information. For example, in wpa_cli:

add_network
set_network 0 ssid "your ssid"
set_network 0 key_mgmt WPA-EAP
set_network 0 eap TTLS
set_network 0 identity "probe"
set_network 0 ca_cert "probe://"
select_network 0
...
CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FI/O=w1.fi/CN=server.w1.fi' cert=30820295308201....


There's going to be number of CTRL-EVENT-EAP-PEER-CERT events listed
here. I'm most interested in the one with depth=0 and cert=<hexdump>
value which is the hexdump of the DER encoding X.509 certificate of the
authentication server. Anyway, if you can send all those
CTRL-EVENT-EAP-PEER-CERT events, that would give even better picture by
including all the CA certificates.
Greg Hudson Feb. 15, 2014, 4:27 p.m. | #4
>> This is all about requiring certain key usage values to be included;
>> there’s nothing about requiring other values to be excluded.

> I know. I was referring to a different specification (sorry, cannot
> talk about details yet).

I'm having trouble imagining a valid reason for anyone to try to
respecify X.509 EKU purposes as restrictive via an embargoed document.
http://tools.ietf.org/html/rfc5280#section-4.2.1.12 makes it clear that
key purposes are permissive, although the presence of an EKU at all is
restrictive (if the application understands what EKUs are or if the
extension is marked critical).

Every web server SSL certificate I can find contains an EKU with
id-kp-clientAuth and id-kp-serverAuth, leading me to believe that CAs
issue certificates with both purposes as a matter of course, and that
this check probably breaks most real-world usage of WPA.
Anders Kaseorg Feb. 16, 2014, 12:05 a.m. | #5
On Sat, 15 Feb 2014, Jouni Malinen wrote:
> I know. I was referring to a different specification (sorry, cannot talk 
> about details yet).

It’s not that I don’t believe you, but you realize how this sounds, right?  
How am I going to supposed to explain to the MIT network team that they 
need to “fix” their certificate that already conforms with every published 
specification and works with every client except wpa_supplicant 2.1?

(Most Linux users aren’t even going to notice this problem for a while 
because Fedora is still on 2.0 and Debian/Ubuntu are stuck at 1.0 because 
of regressions in later versions.  I only noticed because I’m trying to 
help get Debian/Ubuntu unstuck, but I worry that the maintainers aren’t 
going to be encouraged by the current state.)

> To be honest, I did not notice that, but I was thinking of not including 
> id-kp-serverAuth and now that you say it, I guess that could also happen 
> with an EKU (for something completely different) being included. I don't 
> think id-kp-serverAuth is universally used, so I don't really want to 
> mandate it. id-kp-clientAuth alone is actually already rejected by 
> OpenSSL, so no need for that separately in tls_openssl.c.

Okay, then it sounds like the most reasonable solution is reverting commit 
51e3eafb68e15e78e98ca955704be8a6c3a7b304.

> CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FI/O=w1.fi/CN=server.w1.fi' cert=30820295308201....

While trying to extract these certificates, I ran into both a 256-byte 
wpa_cli limit and a 2048-byte wpa_supplicant limit on the length of that 
control message.  After fixing the latter (will send this patch) and 
arbitrarily bumping up the former (we should do something about that too), 
I’ve extracted the following:

<3>CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA' hash=d4c4c99819f3a5f2c6261c9444c62a8b263b39bc6acce35cdcabe272d5037fb2
<3>CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA' cert=308203d9308202c1a00302010202030236d0300d06092a864886f70d01010505003042310b300906035504061302555331163014060355040a130d47656f547275737420496e632e311b30190603550403131247656f547275737420476c6f62616c204341301e170d3130303231393232333932365a170d3230303231383232333932365a3040310b300906035504061302555331173015060355040a130e47656f54727573742c20496e632e311830160603550403130f47656f54727573742053534c20434130820122300d06092a864886f70d01010105000382010f003082010a028201010090b380c1e4e546ad70603dbae514dd9e8a5e8b755ae6ca6d41a523e83985267aa755779a48a1927e3a1e1af127aba34c39cccb3d47af81ae166a5c37ef4541fdfb9a973ca0439dc6df1721d18aa256c203498412813ec90a546066b98c54e4f9e6f994f1e05f7511f229b9e486a2b189ada61e832963b2f0541c850b7ae7e12e0dafa4bdcde7b15ad78c055a0e4b73288b755d34d8770be17462e2713062d8bc8a05e531634a54896a3378a74e55241d97ef1ae412c60f3018b4344de1d8233b215b2d3019250e74f7a4214ba0a420c96ccd9856c0f2a85f3e2675a00df836888a2c5a7d6730a90fd199702e78e15126af557a24be8c390d779dde02c30cbd1f0203010001a381d93081d6300e0603551d0f0101ff040403020106301d0603551d0e041604144279541b61cd552b3e63d53c4857f59ffb45ce4a301f0603551d23041830168014c07a98688d89fbab05640c117daa7d65b8cacc4e30120603551d130101ff040830060101ff020100303a0603551d1f04333031302fa02da02b8629687474703a2f2f63726c2e67656f74727573742e636f6d2f63726c732f6774676c6f62616c2e63726c303406082b0601050507010104283026302406082b060105050730018618687474703a2f2f6f6373702e67656f74727573742e636f6d300d06092a864886f70d01010505000382010100d4ef5384e81abda18b04c0a9f55fa11078455db2576a4e24cb654e3197919ad424f8e2276670319cc1625406e7971d3a9ac0a429480aaf24c7a8c49a54c17c4c784c2b682c5d17a654784c46e280c31f387112d2d753e3548550b802cbee633af856894d55bb2ec0c8187786310b0b70f07e3583a42a13645667345d165f73ac7b0624da4f506d2aabd04d5341c28ebb710349298618cf21424c74625115c56fa8efc427e51b33dd5a88d77f12d1a761251fd5e0dc1dcf1a10d8a0cb5f8cfa0ce5bf71ffe55d441da63e8747fa1a4e8383123f88669598799a85eb0247cd25e3f206044e99ca5ca06e7abbdda3901a4533efbf3ed204c4b6e02a8565413e10d4
<3>CTRL-EVENT-EAP-STATUS status='remote certificate verification' parameter='success'
<3>CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' hash=b4ec7484d07a6a40ad9c700b1ac7557dcceb8f19331449ca0bed9c7c52bba315
<3>CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' cert=308204d1308203b9a003020102020301639f300d06092a864886f70d01010505003040310b300906035504061302555331173015060355040a130e47656f54727573742c20496e632e311830160603550403130f47656f54727573742053534c204341301e170d3132303530313232323730315a170d3137303630333132323430305a3081e63129302706035504051320635679635964754b4a754e2d514a507450524f4f76676735526d7238444d4e68310b3009060355040613025553311630140603550408130d4d617373616368757365747473311230100603550407130943616d627269646765312e302c060355040a13254d61737361636875736574747320496e73746974757465206f6620546563686e6f6c6f6779312c302a060355040b1323496e666f726d6174696f6e20536572766963657320616e6420546563686e6f6c6f67793122302006035504031319776972656c6573732d7261646975732d322e6d69742e65647530820122300d06092a864886f70d01010105000382010f003082010a0282010100daad919238fd2772dc25ee70dcad77051e8802ee35728f038ad3475d5102e603b966ece40ee0ef38c743176e4a85ab05344057baa08bc533a58bf8a6d257d40eac53e23deb26547a8ee159896fbe6c5b83a1487b45176f5dca2c749f05353eba34395c8d9e1e6713c253470d52054ab31b19f5254c2d6b5e91724dc8dca74933154ade57ad83e83371b3dc80bb8384ceed34205893452bb6fe2520fa0e063b2190ea28e2841d9fcafbebe0335e798449d374143b620090fe2894dde8b505665ade13766033108863f0b174da57071852f6e1751cc6f32f4be6bae1971c3433d86f6cbebacb25ef69ddf6d980142b3240e43783e3860023ab991f9419c676404b0203010001a382012b30820127301f0603551d230418301680144279541b61cd552b3e63d53c4857f59ffb45ce4a300e0603551d0f0101ff0404030204b0301d0603551d250416301406082b0601050507030106082b0601050507030230240603551d11041d301b8219776972656c6573732d7261646975732d322e6d69742e656475303d0603551d1f043630343032a030a02e862c687474703a2f2f677473736c2d63726c2e67656f74727573742e636f6d2f63726c732f677473736c2e63726c301d0603551d0e04160414f908c9f752e140281f2fbc6fd4152bfab4a992fb300c0603551d130101ff04023000304306082b0601050507010104373035303306082b060105050730028627687474703a2f2f677473736c2d6169612e67656f74727573742e636f6d2f677473736c2e637274300d06092a864886f70d0101050500038201010041c877631516d82045033bd0730aa35e5ed7032fbdb0312f3a6a3fcdfd93345f68a44b739ec498065f44352aff187918d1ab6be6d85bebda3a5c4f0c8e1287daab02ea62e7c480427b74db973a9002d4822773f6bf433d9c5e0dd53f76303d7aab0ddb2273b247cb930d1dadc805ba51827f8e625d38bfd76c4fbc1764adc02a5925dfa519b33993093ffcdfbadc247ba3af38a44ab22e03856d339f7caa691d1f3cd334589dec4d0c5178e23fe5408f29299fdb7f776240455977d76b54f1abb9ff926b1b3dcf9907e13e512b3f94376dcfd025793be865f1a14b00a12961570c77a270287b43ec329f40ba30a067e46608447564196210b883dfc7543b8c05
<3>CTRL-EVENT-EAP-TLS-CERT-ERROR reason=8 depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' err='Server certificate chain probe'

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 145104 (0x236d0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
        Validity
            Not Before: Feb 19 22:39:26 2010 GMT
            Not After : Feb 18 22:39:26 2020 GMT
        Subject: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:90:b3:80:c1:e4:e5:46:ad:70:60:3d:ba:e5:14:
                    dd:9e:8a:5e:8b:75:5a:e6:ca:6d:41:a5:23:e8:39:
                    85:26:7a:a7:55:77:9a:48:a1:92:7e:3a:1e:1a:f1:
                    27:ab:a3:4c:39:cc:cb:3d:47:af:81:ae:16:6a:5c:
                    37:ef:45:41:fd:fb:9a:97:3c:a0:43:9d:c6:df:17:
                    21:d1:8a:a2:56:c2:03:49:84:12:81:3e:c9:0a:54:
                    60:66:b9:8c:54:e4:f9:e6:f9:94:f1:e0:5f:75:11:
                    f2:29:b9:e4:86:a2:b1:89:ad:a6:1e:83:29:63:b2:
                    f0:54:1c:85:0b:7a:e7:e1:2e:0d:af:a4:bd:cd:e7:
                    b1:5a:d7:8c:05:5a:0e:4b:73:28:8b:75:5d:34:d8:
                    77:0b:e1:74:62:e2:71:30:62:d8:bc:8a:05:e5:31:
                    63:4a:54:89:6a:33:78:a7:4e:55:24:1d:97:ef:1a:
                    e4:12:c6:0f:30:18:b4:34:4d:e1:d8:23:3b:21:5b:
                    2d:30:19:25:0e:74:f7:a4:21:4b:a0:a4:20:c9:6c:
                    cd:98:56:c0:f2:a8:5f:3e:26:75:a0:0d:f8:36:88:
                    8a:2c:5a:7d:67:30:a9:0f:d1:99:70:2e:78:e1:51:
                    26:af:55:7a:24:be:8c:39:0d:77:9d:de:02:c3:0c:
                    bd:1f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Subject Key Identifier: 
                42:79:54:1B:61:CD:55:2B:3E:63:D5:3C:48:57:F5:9F:FB:45:CE:4A
            X509v3 Authority Key Identifier: 
                keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E

            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://crl.geotrust.com/crls/gtglobal.crl

            Authority Information Access: 
                OCSP - URI:http://ocsp.geotrust.com

    Signature Algorithm: sha1WithRSAEncryption
         d4:ef:53:84:e8:1a:bd:a1:8b:04:c0:a9:f5:5f:a1:10:78:45:
         5d:b2:57:6a:4e:24:cb:65:4e:31:97:91:9a:d4:24:f8:e2:27:
         66:70:31:9c:c1:62:54:06:e7:97:1d:3a:9a:c0:a4:29:48:0a:
         af:24:c7:a8:c4:9a:54:c1:7c:4c:78:4c:2b:68:2c:5d:17:a6:
         54:78:4c:46:e2:80:c3:1f:38:71:12:d2:d7:53:e3:54:85:50:
         b8:02:cb:ee:63:3a:f8:56:89:4d:55:bb:2e:c0:c8:18:77:86:
         31:0b:0b:70:f0:7e:35:83:a4:2a:13:64:56:67:34:5d:16:5f:
         73:ac:7b:06:24:da:4f:50:6d:2a:ab:d0:4d:53:41:c2:8e:bb:
         71:03:49:29:86:18:cf:21:42:4c:74:62:51:15:c5:6f:a8:ef:
         c4:27:e5:1b:33:dd:5a:88:d7:7f:12:d1:a7:61:25:1f:d5:e0:
         dc:1d:cf:1a:10:d8:a0:cb:5f:8c:fa:0c:e5:bf:71:ff:e5:5d:
         44:1d:a6:3e:87:47:fa:1a:4e:83:83:12:3f:88:66:95:98:79:
         9a:85:eb:02:47:cd:25:e3:f2:06:04:4e:99:ca:5c:a0:6e:7a:
         bb:dd:a3:90:1a:45:33:ef:bf:3e:d2:04:c4:b6:e0:2a:85:65:
         41:3e:10:d4
-----BEGIN CERTIFICATE-----
MIID2TCCAsGgAwIBAgIDAjbQMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i
YWwgQ0EwHhcNMTAwMjE5MjIzOTI2WhcNMjAwMjE4MjIzOTI2WjBAMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOR2VvVHJ1c3QsIEluYy4xGDAWBgNVBAMTD0dlb1RydXN0
IFNTTCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJCzgMHk5Uat
cGA9uuUU3Z6KXot1WubKbUGlI+g5hSZ6p1V3mkihkn46HhrxJ6ujTDnMyz1Hr4Gu
FmpcN+9FQf37mpc8oEOdxt8XIdGKolbCA0mEEoE+yQpUYGa5jFTk+eb5lPHgX3UR
8im55IaisYmtph6DKWOy8FQchQt65+EuDa+kvc3nsVrXjAVaDktzKIt1XTTYdwvh
dGLicTBi2LyKBeUxY0pUiWozeKdOVSQdl+8a5BLGDzAYtDRN4dgjOyFbLTAZJQ50
96QhS6CkIMlszZhWwPKoXz4mdaAN+DaIiixafWcwqQ/RmXAueOFRJq9VeiS+jDkN
d53eAsMMvR8CAwEAAaOB2TCB1jAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEJ5
VBthzVUrPmPVPEhX9Z/7Rc5KMB8GA1UdIwQYMBaAFMB6mGiNifurBWQMEX2qfWW4
ysxOMBIGA1UdEwEB/wQIMAYBAf8CAQAwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDov
L2NybC5nZW90cnVzdC5jb20vY3Jscy9ndGdsb2JhbC5jcmwwNAYIKwYBBQUHAQEE
KDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5nZW90cnVzdC5jb20wDQYJKoZI
hvcNAQEFBQADggEBANTvU4ToGr2hiwTAqfVfoRB4RV2yV2pOJMtlTjGXkZrUJPji
J2ZwMZzBYlQG55cdOprApClICq8kx6jEmlTBfEx4TCtoLF0XplR4TEbigMMfOHES
0tdT41SFULgCy+5jOvhWiU1Vuy7AyBh3hjELC3DwfjWDpCoTZFZnNF0WX3OsewYk
2k9QbSqr0E1TQcKOu3EDSSmGGM8hQkx0YlEVxW+o78Qn5Rsz3VqI138S0adhJR/V
4NwdzxoQ2KDLX4z6DOW/cf/lXUQdpj6HR/oaToODEj+IZpWYeZqF6wJHzSXj8gYE
TpnKXKBuervdo5AaRTPvvz7SBMS24CqFZUE+ENQ=
-----END CERTIFICATE-----

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 91039 (0x1639f)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA
        Validity
            Not Before: May  1 22:27:01 2012 GMT
            Not After : Jun  3 12:24:00 2017 GMT
        Subject: serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh, C=US, ST=Massachusetts, L=Cambridge, O=Massachusetts Institute of Technology, OU=Information Services and Technology, CN=wireless-radius-2.mit.edu
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:da:ad:91:92:38:fd:27:72:dc:25:ee:70:dc:ad:
                    77:05:1e:88:02:ee:35:72:8f:03:8a:d3:47:5d:51:
                    02:e6:03:b9:66:ec:e4:0e:e0:ef:38:c7:43:17:6e:
                    4a:85:ab:05:34:40:57:ba:a0:8b:c5:33:a5:8b:f8:
                    a6:d2:57:d4:0e:ac:53:e2:3d:eb:26:54:7a:8e:e1:
                    59:89:6f:be:6c:5b:83:a1:48:7b:45:17:6f:5d:ca:
                    2c:74:9f:05:35:3e:ba:34:39:5c:8d:9e:1e:67:13:
                    c2:53:47:0d:52:05:4a:b3:1b:19:f5:25:4c:2d:6b:
                    5e:91:72:4d:c8:dc:a7:49:33:15:4a:de:57:ad:83:
                    e8:33:71:b3:dc:80:bb:83:84:ce:ed:34:20:58:93:
                    45:2b:b6:fe:25:20:fa:0e:06:3b:21:90:ea:28:e2:
                    84:1d:9f:ca:fb:eb:e0:33:5e:79:84:49:d3:74:14:
                    3b:62:00:90:fe:28:94:dd:e8:b5:05:66:5a:de:13:
                    76:60:33:10:88:63:f0:b1:74:da:57:07:18:52:f6:
                    e1:75:1c:c6:f3:2f:4b:e6:ba:e1:97:1c:34:33:d8:
                    6f:6c:be:ba:cb:25:ef:69:dd:f6:d9:80:14:2b:32:
                    40:e4:37:83:e3:86:00:23:ab:99:1f:94:19:c6:76:
                    40:4b
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:42:79:54:1B:61:CD:55:2B:3E:63:D5:3C:48:57:F5:9F:FB:45:CE:4A

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                DNS:wireless-radius-2.mit.edu
            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://gtssl-crl.geotrust.com/crls/gtssl.crl

            X509v3 Subject Key Identifier: 
                F9:08:C9:F7:52:E1:40:28:1F:2F:BC:6F:D4:15:2B:FA:B4:A9:92:FB
            X509v3 Basic Constraints: critical
                CA:FALSE
            Authority Information Access: 
                CA Issuers - URI:http://gtssl-aia.geotrust.com/gtssl.crt

    Signature Algorithm: sha1WithRSAEncryption
         41:c8:77:63:15:16:d8:20:45:03:3b:d0:73:0a:a3:5e:5e:d7:
         03:2f:bd:b0:31:2f:3a:6a:3f:cd:fd:93:34:5f:68:a4:4b:73:
         9e:c4:98:06:5f:44:35:2a:ff:18:79:18:d1:ab:6b:e6:d8:5b:
         eb:da:3a:5c:4f:0c:8e:12:87:da:ab:02:ea:62:e7:c4:80:42:
         7b:74:db:97:3a:90:02:d4:82:27:73:f6:bf:43:3d:9c:5e:0d:
         d5:3f:76:30:3d:7a:ab:0d:db:22:73:b2:47:cb:93:0d:1d:ad:
         c8:05:ba:51:82:7f:8e:62:5d:38:bf:d7:6c:4f:bc:17:64:ad:
         c0:2a:59:25:df:a5:19:b3:39:93:09:3f:fc:df:ba:dc:24:7b:
         a3:af:38:a4:4a:b2:2e:03:85:6d:33:9f:7c:aa:69:1d:1f:3c:
         d3:34:58:9d:ec:4d:0c:51:78:e2:3f:e5:40:8f:29:29:9f:db:
         7f:77:62:40:45:59:77:d7:6b:54:f1:ab:b9:ff:92:6b:1b:3d:
         cf:99:07:e1:3e:51:2b:3f:94:37:6d:cf:d0:25:79:3b:e8:65:
         f1:a1:4b:00:a1:29:61:57:0c:77:a2:70:28:7b:43:ec:32:9f:
         40:ba:30:a0:67:e4:66:08:44:75:64:19:62:10:b8:83:df:c7:
         54:3b:8c:05
-----BEGIN CERTIFICATE-----
MIIE0TCCA7mgAwIBAgIDAWOfMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM
IENBMB4XDTEyMDUwMTIyMjcwMVoXDTE3MDYwMzEyMjQwMFowgeYxKTAnBgNVBAUT
IGNWeWNZZHVLSnVOLVFKUHRQUk9PdmdnNVJtcjhETU5oMQswCQYDVQQGEwJVUzEW
MBQGA1UECBMNTWFzc2FjaHVzZXR0czESMBAGA1UEBxMJQ2FtYnJpZGdlMS4wLAYD
VQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MSwwKgYD
VQQLEyNJbmZvcm1hdGlvbiBTZXJ2aWNlcyBhbmQgVGVjaG5vbG9neTEiMCAGA1UE
AxMZd2lyZWxlc3MtcmFkaXVzLTIubWl0LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBANqtkZI4/Sdy3CXucNytdwUeiALuNXKPA4rTR11RAuYDuWbs
5A7g7zjHQxduSoWrBTRAV7qgi8UzpYv4ptJX1A6sU+I96yZUeo7hWYlvvmxbg6FI
e0UXb13KLHSfBTU+ujQ5XI2eHmcTwlNHDVIFSrMbGfUlTC1rXpFyTcjcp0kzFUre
V62D6DNxs9yAu4OEzu00IFiTRSu2/iUg+g4GOyGQ6ijihB2fyvvr4DNeeYRJ03QU
O2IAkP4olN3otQVmWt4TdmAzEIhj8LF02lcHGFL24XUcxvMvS+a64ZccNDPYb2y+
ussl72nd9tmAFCsyQOQ3g+OGACOrmR+UGcZ2QEsCAwEAAaOCASswggEnMB8GA1Ud
IwQYMBaAFEJ5VBthzVUrPmPVPEhX9Z/7Rc5KMA4GA1UdDwEB/wQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwJAYDVR0RBB0wG4IZd2lyZWxlc3Mt
cmFkaXVzLTIubWl0LmVkdTA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vZ3Rzc2wt
Y3JsLmdlb3RydXN0LmNvbS9jcmxzL2d0c3NsLmNybDAdBgNVHQ4EFgQU+QjJ91Lh
QCgfL7xv1BUr+rSpkvswDAYDVR0TAQH/BAIwADBDBggrBgEFBQcBAQQ3MDUwMwYI
KwYBBQUHMAKGJ2h0dHA6Ly9ndHNzbC1haWEuZ2VvdHJ1c3QuY29tL2d0c3NsLmNy
dDANBgkqhkiG9w0BAQUFAAOCAQEAQch3YxUW2CBFAzvQcwqjXl7XAy+9sDEvOmo/
zf2TNF9opEtznsSYBl9ENSr/GHkY0atr5thb69o6XE8MjhKH2qsC6mLnxIBCe3Tb
lzqQAtSCJ3P2v0M9nF4N1T92MD16qw3bInOyR8uTDR2tyAW6UYJ/jmJdOL/XbE+8
F2StwCpZJd+lGbM5kwk//N+63CR7o684pEqyLgOFbTOffKppHR880zRYnexNDFF4
4j/lQI8pKZ/bf3diQEVZd9drVPGruf+Saxs9z5kH4T5RKz+UN23P0CV5O+hl8aFL
AKEpYVcMd6JwKHtD7DKfQLowoGfkZghEdWQZYhC4g9/HVDuMBQ==
-----END CERTIFICATE-----

Anders
Jouni Malinen Feb. 16, 2014, 8:35 a.m. | #6
On Sat, Feb 15, 2014 at 07:05:05PM -0500, Anders Kaseorg wrote:
> How am I going to supposed to explain to the MIT network team that they 
> need to “fix” their certificate that already conforms with every published 
> specification and works with every client except wpa_supplicant 2.1?

Just to be clear: I have not and do not in any way suggest that the AAA
server certificate here should be changed.

> Okay, then it sounds like the most reasonable solution is reverting commit 
> 51e3eafb68e15e78e98ca955704be8a6c3a7b304.

Probably yes. The unfortunate part here is that there seems to be a
conflicting requirement in this area. Hopefully, that requirement can be
changed, but if not, this is going to be much wider issue and something
else is going to be needed to work around this.

> While trying to extract these certificates, I ran into both a 256-byte 
> wpa_cli limit and a 2048-byte wpa_supplicant limit on the length of that 
> control message.  After fixing the latter (will send this patch) and 
> arbitrarily bumping up the former (we should do something about that too), 
> I’ve extracted the following:

Thanks! This is exactly the information I need for trying to get the
requirement side resolved.
Jouni Malinen Feb. 19, 2014, 1:25 p.m. | #7
On Sat, Feb 15, 2014 at 07:05:05PM -0500, Anders Kaseorg wrote:
> Okay, then it sounds like the most reasonable solution is reverting commit 
> 51e3eafb68e15e78e98ca955704be8a6c3a7b304.

I did that now. I don't yet know what will happen with the other
conflicting requirements in this area, but I'll try to get them changed
and at least keep this use case in mind as far as wpa_supplicant
implementation is concerned. There is now a regression test case that
verifies interop with this type of AAA server certificate.

Patch

diff --git a/src/crypto/tls.h b/src/crypto/tls.h
index 287fd33..3f07600 100644
--- a/src/crypto/tls.h
+++ b/src/crypto/tls.h
@@ -42,7 +42,7 @@  enum tls_fail_reason {
 	TLS_FAIL_BAD_CERTIFICATE = 7,
 	TLS_FAIL_SERVER_CHAIN_PROBE = 8,
 	TLS_FAIL_DOMAIN_SUFFIX_MISMATCH = 9,
-	TLS_FAIL_SERVER_USED_CLIENT_CERT = 10
+	TLS_FAIL_NON_SERVER_KEY_USAGE = 10,
 };
 
 union tls_event_data {
diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
index d025ae0..485a21e 100644
--- a/src/crypto/tls_openssl.c
+++ b/src/crypto/tls_openssl.c
@@ -1479,11 +1479,13 @@  static int tls_verify_cb(int preverify_ok, X509_STORE_CTX *x509_ctx)
 
 	if (!conn->server && err_cert && preverify_ok && depth == 0 &&
 	    (err_cert->ex_flags & EXFLAG_XKUSAGE) &&
-	    (err_cert->ex_xkusage & XKU_SSL_CLIENT)) {
-		wpa_printf(MSG_WARNING, "TLS: Server used client certificate");
+	    !(err_cert->ex_xkusage & XKU_SSL_SERVER)) {
+		wpa_printf(MSG_WARNING, "TLS: Server certificate marked for "
+			   "non-server key usage");
 		openssl_tls_fail_event(conn, err_cert, err, depth, buf,
-				       "Server used client certificate",
-				       TLS_FAIL_SERVER_USED_CLIENT_CERT);
+				       "Server certificate marked for "
+				       "non-server key usage",
+				       TLS_FAIL_NON_SERVER_KEY_USAGE);
 		preverify_ok = 0;
 	}