[openssl-users] Behaviour of OpenSSL when CApath or CAfile contains a 'trusted certificate' with all uses rejected

Thu Jan 15 12:52:18 UTC 2015

Whew, that was a long title!

Hi, folks. I'm a Fedora QA person who's been poking at SSL stuff as a 
sort of sideline lately; please don't give me too much credit for my 
email address, I'm not one of RH's official security / SSL folks, so 
please be gentle when I'm wrong ;)

This is all with OpenSSL 1.0.1k on Fedora Rawhide.

Lately I've been trying to figure out if it's possible / desirable to 
switch to using the OpenSSL 'trusted certificate' format (the one 
whose PEM-encoded certificates have 'BEGIN TRUSTED CERTIFICATE' rather 
than 'BEGIN CERTIFICATE') for a distribution's trust store.

The case I'm (currently) interested in is what exactly happens if you 
try to distrust a CA using the 'trusted certificate' system.

To this end, I've been doing some tests. I'm using the certificate 
chain that's used by my personal domain (https://www.happyassassin.net 
), so it should be quite easy to reproduce. My certificate is a 
StartCom level 2 cert; the root CA cert is 
http://www.startssl.com/certs/ca.pem and the intermediate CA cert is 
http://www.startssl.com/certs/sub.class2.server.ca.pem , my server 
certificate is attached for convenience or can easily be retrieved 
from...the server.

I'm using Fedora's p11-kit-based trust store generation system. If I 
put ca.pem in /etc/pki/ca-trust/source/blacklist , run `update-ca-
trust` and then `trust extract --format=openssl-directory --filter 
blacklist black` , what p11-kit does is generate a 'TRUSTED 
CERTIFICATE' format certificate file named 
StartCom_Certification_Authority.pem for the blacklisted CA and place 
it in the directory 'black' (if you actually try this you'll also get a
few other files in there, for CAs that are blacklisted by system 
policy). (The '--filter blacklist' stops it also generating files for 
all the trusted CAs, just to keep things clean). It also generates the 
necessary hash symlinks for OpenSSL to treat the directory as a 
CApath, of course. If you run `openssl x509 -in 
black/StartCom_Certification_Authority.pem -noout -text`, you see how 
p11-kit tries to use the 'TRUSTED CERTIFICATE' extensions to indicate 
that the CA should not be trusted:

No Trusted Uses.
Rejected Uses:
  TLS Web Server Authentication, TLS Web Client Authentication, Code 
Signing, E-mail Protection, IPSec End System, IPSec Tunnel, IPSec 
User, Time Stamping

So, hopefully that picture's clear? The intent is that if you use 
black/ as the CApath for validation, certs issued by that CA should 
not be trusted.

For comparison, I have the directory white/ , which contains p11-kit's 
output for the same CA when whitelisted / trusted:

Trusted Uses:
  E-mail Protection, TLS Web Server Authentication, Code Signing
No Rejected Uses.

In one of my test cases, this seems to work pretty well. I just try to 
connect to my server with s_client, using the two different CApaths. 
black:

[adamw at adam tmp]$ openssl s_client -CApath black/ -connect www.happyassassin.net:443
...
verify error:num=28:certificate rejected
verify return:0
...
Verify return code: 28 (certificate rejected)

white:

[adamw at adam tmp]$ openssl s_client -CApath white/ -connect www.happyassassin.net:443
...
verify return:1
...
Verify return code: 0 (ok)

However, if I use 'openssl verify' (and provide the intermediate cert 
with -untrusted), it doesn't work as expected. No errors occur, even 
with the 'black' CApath.

[adamw at adam tmp]$ openssl verify -CApath black/ -untrusted sub.class2.server.ca.pem www.happyassassin.net.crt
www.happyassassin.net.crt: OK

Even if I pass a purpose:

[adamw at adam tmp]$ openssl verify -purpose sslserver -CApath black/ -untrusted sub.class2.server.ca.pem www.happyassassin.net.crt
www.happyassassin.net.crt: OK

The outputs of `openssl x509 -in 
white/StartCom_Certification_Authority.pem -noout -purpose` and 
`openssl x509 -in black/StartCom_Certification_Authority.pem -noout -
purpose` are identical.

I've been staring at the code and docs for this for several hours to 
try and figure out what the difference between the 'verify' and 
's_client' paths is, and I finally had to sort of throw up my hands 
and admit defeat, and come and ask for help :)

It seems to me that it must be the case, somehow, that on the 'openssl 
verify' path the root certificate just isn't run through 
X509_check_trust(). But I can't see why not. To my idiot eyes, 
verify.c's check() and ssl_cert.c's ssl_verify_cert_chain() look like 
they do more or less the same thing, and verify.c's verify_callback 
doesn't seem to suppress any errors.

After a lot of searching I did satisfy myself that anything that goes 
through ssl3_connect() gets a default purpose and trust (it had been 
suggested on the RH bug that only consumers which explicitly set these 
would get one), but that doesn't explain why 'openssl verify' works 
even with a -purpose.

If anyone can point out what I'm missing I'd be very grateful :)

As well as my server cert I'll attach the 'black' and 'white' .pem 
files and the intermediate cert.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: www.happyassassin.net.crt
Type: application/pkix-cert
Size: 2748 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150115/745829bb/attachment-0001.bin>
-------------- next part --------------
-----BEGIN TRUSTED CERTIFICATE-----
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14wdKBQBggrBgEFBQcDAQYIKwYB
BQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwUGCCsGAQUFBwMGBggr
BgEFBQcDBwYIKwYBBQUHAwgMIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5
-----END TRUSTED CERTIFICATE-----
-------------- next part --------------
-----BEGIN TRUSTED CERTIFICATE-----
MIIHyTCCBbGgAwIBAgIBATANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM2WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICUjCCAk4wDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAa4wHQYDVR0OBBYE
FE4L7xqkQFulF2mHMMo0aEPQQa7yMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j
ZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3Js
LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwuY3JsMIIBXQYDVR0gBIIBVDCCAVAwggFM
BgsrBgEEAYG1NwEBATCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3Rh
cnQgQ29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlh
YmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg
dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFp
bGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJ
YIZIAYb4QgEBBAQDAgAHMDgGCWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTANBgkqhkiG9w0BAQUFAAOCAgEAFmyZ
9GYMNPXQhV59CuzaEE44HF7fpiUFS5Eyweg78T3dRAlbB0mKKctmArexmvclmAk8
jhvh3TaHK0u7aNM5Zj2gJsfyOZEdUauCe37Vzlrk4gNXcGmXCPleWKYK34wGmkUW
FjgKXlf2Ysd6AgXmvB618p70qSmD+LIU424oh0TDkBreOKk8rENNZEXO3SipXPJz
ewT4F+irsfMuXGRuczE6Eri8sxHkfY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1
ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3fsNrarnDy0RLrHiQi+fHLB5L
EUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZEoalHmdkrQYu
L6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuC
O3NJo2pXh5Tl1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6V
um0ABj6y6koQOdjQK/W/7HW/lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkySh
NOsF/5oirpt9P/FlUQqmMGqz9IgcgA38corog14wQjAeBggrBgEFBQcDBAYIKwYB
BQUHAwEGCCsGAQUFBwMDDCBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eQ==
-----END TRUSTED CERTIFICATE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sub.class2.server.ca.pem
Type: application/x-x509-ca-cert
Size: 2212 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150115/745829bb/attachment-0001.crt>