certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
Folks, Have a CA (created by certtool, validates in openssl as self signed just fine) and a server cert (created with certtool, signed with certool) which des NOT validate in openssl. However the signature (when extracted with openssl its asn1parse; openssl its rsautl and openssl its sha256) looks correct. And it seems to be accepted by the NSS and apple their stack. Any suggestions? Not unlikely this is sha256 specific - as that is what triggered this. Tried against 1.0.1c and 0.9.8q (with the latter of course not do the SHA256). Thanks. Dw. $ openssl verify -CAfile ca.pem ca.pem ca.pem: OK $ openssl verify -CAfile ca.pem x.pem x.pem: O = MedVision360 Test Org, CN = svc01.local error 7 at 0 depth lookup:certificate signature failure 140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175: 140735152787932:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Which errors out. Extracting the signature manually with $ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 $ openssl x509 -in x.pem -pubkey -noout x.rsa $ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin $ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04 s.=..3.. 0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62 (d.i.t*.E.cb $ openssl sha256 -c x.tbs SHA256(x.tbs)= 73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62 looks actually good. As does the ANS1 it seems. ca.pem Description: Binary data x.pem Description: Binary data example.sh Description: Binary data
Re: certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
On 14 nov. 2012, at 18:42, Dirk-Willem van Gulik di...@webweaving.org wrote: Have a CA (created by certtool, validates in openssl as self signed just fine) and a server cert (created with certtool, signed with certool) which des NOT validate in openssl. However the signature (when extracted with openssl its asn1parse; openssl its rsautl and openssl its sha256) looks correct. And it seems to be accepted by the NSS and apple their stack. As well as java its native and bouncy-castle stack. So this starts to feel a bit like a openssl bug. Any suggestions? Not unlikely this is sha256 specific - as that is what triggered this. Tried against 1.0.1c and 0.9.8q (with the latter of course not do the SHA256). Thanks. Dw. $ openssl verify -CAfile ca.pem ca.pem ca.pem: OK $ openssl verify -CAfile ca.pem x.pem x.pem: O = MedVision360 Test Org, CN = svc01.local error 7 at 0 depth lookup:certificate signature failure 140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175: 140735152787932:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Which errors out. Extracting the signature manually with $ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 $ openssl x509 -in x.pem -pubkey -noout x.rsa $ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin $ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04 s.=..3.. 0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62 (d.i.t*.E.cb $ openssl sha256 -c x.tbs SHA256(x.tbs)= 73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62 looks actually good. As does the ANS1 it seems #!/bin/sh cat ca.pem EOM -BEGIN CERTIFICATE- MIIEmjCCA1KgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBnjEUMBIGA1UEBhMLTmV0 aGVybGFuZHMxHjAcBgNVBAoTFU1lZFZpc2lvbjM2MCBUZXN0IE9yZzETMBEGA1UE CxMKT3BlcmF0aW9uczEPMA0GA1UEBxMGTGVpZGVuMQswCQYDVQQIEwJaSDERMA8G A1UEAxMIbWFuYWdlMDExIDAeBgoJkiaJk/IsZAEBExBNZWRWaXNpb24zNjBUZXN0 MB4XDTEyMTExNDE1NTExNloXDTM0MDMyNDE1NTExNlowgZ4xFDASBgNVBAYTC05l dGhlcmxhbmRzMR4wHAYDVQQKExVNZWRWaXNpb24zNjAgVGVzdCBPcmcxEzARBgNV BAsTCk9wZXJhdGlvbnMxDzANBgNVBAcTBkxlaWRlbjELMAkGA1UECBMCWkgxETAP BgNVBAMTCG1hbmFnZTAxMSAwHgYKCZImiZPyLGQBARMQTWVkVmlzaW9uMzYwVGVz dDCCAVIwDQYJKoZIhvcNAQEBBQADggE/ADCCAToCggExAL+1c8zar0gKXX2MiHn3 CHde2aDi6clEeeYelFDKA53tht54yqRUWLiGnCkeVgCz943FUkyR42cKOemVIgzr rWoh/OlJBxNKVCnOFCONT9cU9yuoM67y7grSwLPPAu9icSvNgB8Mx6i+ffkUDuJi tqAEuBX3pkmtfSl6xCOq4eO2Mvye8RKh16hKqX+JON5v8l8In0kO265Q17k7E11Z uXNFRaNG1CiTw07fTCWLhwhFDu7bDSqzcyY4aXwV5FYacOzQmMKyDn8srWPz73WO dQ9wEJPgZ5B/01ZwJD7wMGck4zpTUq8sw2Db7VVLfiBdWanCDLYRjfa2lq8SBW4Z 4jrhw1e8CI1NM+ZkXIn8Ia+IY636atTG1IGE5fXlRmBNZd8m+Ocg3Ugyu0ak+u4y OWcCAwEAAaOBgDB+MA8GA1UdEwEB/wQFMAMBAf8wGgYDVR0RBBMwEYEPcm9vdEBs b2NhbGhvc3QgMB0GA1UdDgQWBBQh8IYoZPiXBhK3PEedxwmig64ovTAwBgNVHR8E KTAnMCWgI6Ahhh9odHRwOi8vY2EubWVkdmlzaW9uLm9yZy9nZXRjcmwvMA0GCSqG SIb3DQEBCwUAA4IBMQBAU6Wzex1UMMfpjY07qO0IdyRRAD5qfxLmosT8xACqMUFC jUy9ckvLm2lPgUk4P7zkIuVn4r52cGQNthCIhmuYQ0fBz4h4Xm7NIOrSkI9oN12m UWd3dv8zesP5FWoKtS57w/w+gEpjgyKUHPSVZdIJlIW0J6eFTwGonxcdsM/yWFRD zbyNSYNT/aNqkaO/vn3S8LvV58AnGZXyU2Ck/N5xmk7DS+CLR2Nk6VAXNF/oIygb 1arPsWJIbrysHw2SbpKbZYG7CL8STm8/4oRtelUFT8uvPkpsLOB1e1RSbo7lc5o2 MAutVoFffz0LKISQ8AGH4q+SnT2k/HWRjqDuGz7sumVQ3i0NWcUA9nXhtMJCG7QO lMSrO6OEcHx674rUNmo2W38LChvJMe10ec0W9qNc -END CERTIFICATE- EOM cat x.pem EOM -BEGIN CERTIFICATE- MIIEPTCCAyWgAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBnjEUMBIGA1UEBhMLTmV0 aGVybGFuZHMxHjAcBgNVBAoTFU1lZFZpc2lvbjM2MCBUZXN0IE9yZzETMBEGA1UE CxMKT3BlcmF0aW9uczEPMA0GA1UEBxMGTGVpZGVuMQswCQYDVQQIEwJaSDERMA8G A1UEAxMIbWFuYWdlMDExIDAeBgoJkiaJk/IsZAEBExBNZWRWaXNpb24zNjBUZXN0 MB4XDTEyMTExNDE2NDIzM1oXDTM0MDMyNDE2NDIzM1owNjEeMBwGA1UEChMVTWVk VmlzaW9uMzYwIFRlc3QgT3JnMRQwEgYDVQQDEwtzdmMwMS5sb2NhbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANXXd/mo9KTadZqinXDmApo0Nh4lokCb kdRWkdKQgPo1j0VTYRBdv5qEZsy4wE1mu5Z4uMrK//aU6ZyAn261pJueqwsNSljF AAoX86vFmmybuJ3ubazkcH6wOv4pF1vrMtZwdXazxA6jiqevvTOI7EOMmEwW3BDw xbFjR67WETrK5r6ohSX7pdZCIjShnO1timad8zMY+2iBM0UiM3MwLyhEgqyYlumd uzQNs10Iz7qgnL2Hlq/MVbcazFUgup/QSiMioXazsO88nMVhnh9YdAdhxqKN6xzW 0w/bieOwfKJHEFosvK19wHvxgepFpFuy2J83s+CoLm9aEHi2Xk6dhAMCAwEAAaOB 7DCB6TAjBgNVHREEHDAaggtzdmMwMS5sb2NhbIILc3ZjMDEubG9jYWwwDAYDVR0T AQH/BAIwADAPBgNVHQ8BAf8EBQMDB6AAMDEGA1UdJQQqMCgGCCsGAQUFBwMCBggr BgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMBMB0GA1UdDgQWBBQDCveQj8OFuRbc ZMLONGOLrmdo8DAfBgNVHSMEGDAWgBQh8IYoZPiXBhK3PEedxwmig64ovTAwBgNV HR8EKTAnMCWgI6Ahhh9odHRwOi8vY2EubWVkdmlzaW9uLm9yZy9nZXRjcmwvMA0G CSqGSIb3DQEBCwUAA4IBAQCfKE2n1feT7b3bepsePOx7LAStmRum0DPtBEpJ/o0U
Re: certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
On Wed, Nov 14, 2012, Dirk-Willem van Gulik wrote:
Folks,
Have a CA (created by certtool, validates in openssl as self signed just
fine) and a server cert (created with certtool, signed with certool) which
des NOT validate in openssl.
However the signature (when extracted with openssl its asn1parse; openssl its
rsautl and openssl its sha256) looks correct.
And it seems to be accepted by the NSS and apple their stack.
Any suggestions? Not unlikely this is sha256 specific - as that is what
triggered this.
Tried against 1.0.1c and 0.9.8q (with the latter of course not do the
SHA256).
Thanks.
Dw.
$ openssl verify -CAfile ca.pem ca.pem
ca.pem: OK
$ openssl verify -CAfile ca.pem x.pem
x.pem: O = MedVision360 Test Org, CN = svc01.local
error 7 at 0 depth lookup:certificate signature failure
140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
signature length:rsa_sign.c:175:
140735152787932:error:0D0C5006:asn1 encoding
routines:ASN1_item_verify:EVP lib:a_verify.c:215:
Which errors out. Extracting the signature manually with
$ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828
$ openssl x509 -in x.pem -pubkey -noout x.rsa
$ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin
$ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4
0:d=0 hl=2 l= 49 cons: SEQUENCE
2:d=1 hl=2 l= 13 cons: SEQUENCE
4:d=2 hl=2 l= 9 prim: OBJECT:sha256
15:d=2 hl=2 l= 0 prim: NULL
17:d=1 hl=2 l= 32 prim: OCTET STRING
- 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04
s.=..3..
0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62
(d.i.t*.E.cb
$ openssl sha256 -c x.tbs
SHA256(x.tbs)=
73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62
looks actually good. As does the ANS1 it seems.
That would be OK if x.pem is self signed but it is not. The signature in x.pem
needs to be checked by the key in its CA which in this case is ca.pem. If you
look at the ca.pem certificate its key is 2432 bits in size while the
signature in x.pem is 2048 bits: that's why you get the error.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl-users] Re: certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
In addition to Mr Henson answer, your CA certificate doesn't have any keyUsage extension, depending on the toolkit it may not be considered a valid CA. Your countryName AVA is wrong, too. It must be only 2 characters long, NL in your case. -- Erwann ABALEA - yuppiexpédidétritus: cadavres gelés de grimpeurs occidentaux jonchant l'Everest parmi les yakocoprolithes Le 14/11/2012 19:16, Dirk-Willem van Gulik a écrit : On 14 nov. 2012, at 18:42, Dirk-Willem van Gulik di...@webweaving.org wrote: Have a CA (created by certtool, validates in openssl as self signed just fine) and a server cert (created with certtool, signed with certool) which des NOT validate in openssl. However the signature (when extracted with openssl its asn1parse; openssl its rsautl and openssl its sha256) looks correct. And it seems to be accepted by the NSS and apple their stack. As well as java its native and bouncy-castle stack. So this starts to feel a bit like a openssl bug. Any suggestions? Not unlikely this is sha256 specific - as that is what triggered this. Tried against 1.0.1c and 0.9.8q (with the latter of course not do the SHA256). Thanks. Dw. $ openssl verify -CAfile ca.pem ca.pem ca.pem: OK $ openssl verify -CAfile ca.pem x.pem x.pem: O = MedVision360 Test Org, CN = svc01.local error 7 at 0 depth lookup:certificate signature failure 140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175: 140735152787932:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Which errors out. Extracting the signature manually with $ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 $ openssl x509 -in x.pem -pubkey -noout x.rsa $ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin $ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04 s.=..3.. 0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62 (d.i.t*.E.cb $ openssl sha256 -c x.tbs SHA256(x.tbs)= 73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62 looks actually good. As does the ANS1 it seems __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: certool v.s. openssl - broken/mis-interpreted sha256 cert issue.
On 14 nov. 2012, at 19:58, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Nov 14, 2012, Dirk-Willem van Gulik wrote: Folks, Have a CA (created by certtool, validates in openssl as self signed just fine) and a server cert (created with certtool, signed with certool) which des NOT validate in openssl. However the signature (when extracted with openssl its asn1parse; openssl its rsautl and openssl its sha256) looks correct. And it seems to be accepted by the NSS and apple their stack. Any suggestions? Not unlikely this is sha256 specific - as that is what triggered this. Tried against 1.0.1c and 0.9.8q (with the latter of course not do the SHA256). Thanks. Dw. $ openssl verify -CAfile ca.pem ca.pem ca.pem: OK $ openssl verify -CAfile ca.pem x.pem x.pem: O = MedVision360 Test Org, CN = svc01.local error 7 at 0 depth lookup:certificate signature failure 140735152787932:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175: 140735152787932:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:215: Which errors out. Extracting the signature manually with $ openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 $ openssl x509 -in x.pem -pubkey -noout x.rsa $ openssl rsautl -in x.sig -verify -asn1parse -inkey x.rsa -pubin $ openssl asn1parse -in x.pem -out x.tbs -noout -strparse 4 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT:sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING - 73 87 b0 9d e8 15 9f fb-ce af 3d ef 18 33 b3 04 s.=..3.. 0010 - 28 64 b5 85 e9 88 91 69-e9 74 2a e6 45 ea 63 62 (d.i.t*.E.cb $ openssl sha256 -c x.tbs SHA256(x.tbs)= 73:87:b0:9d:e8:15:9f:fb:ce:af:3d:ef:18:33:b3:04:28:64:b5:85:e9:88:91:69:e9:74:2a:e6:45:ea:63:62 looks actually good. As does the ANS1 it seems. That would be OK if x.pem is self signed but it is not. The signature in x.pem needs to be checked by the key in its CA which in this case is ca.pem. If you look at the ca.pem certificate its key is 2432 bits in size while the signature in x.pem is 2048 bits: that's why you get the error. Thanks - so extracting that: openssl x509 -in ca.pem -pubkey -noout | openssl rsa -text -pubin .. Public-Key: (2432 bit) .. so the RSA signature on x.pem its sha256 should have been 2432 bits in length. And it is not: openssl asn1parse -in x.pem -out x.sig -noout -strparse 828 wc -c x.sig 256 x.sig (2048 bits) it is 2048 bits in size. Is that the correct reasoning ? And I need to assume that the other tools are somehow getting confused and then accept it. Correct ? Dw.__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
