Re: Verification of a x509 certificate signature
Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a x509 certificate signature
the ASN.1 dump of this certificate ... 0 470: SEQUENCE { 4 319: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 5: INTEGER 00 D6 2D F4 34 20 13: SEQUENCE { 22 9: OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5) 33 0: NULL : } 35 20: SEQUENCE { 37 18: SET { 39 16: SEQUENCE { 41 3: OBJECT IDENTIFIER commonName (2 5 4 3) 46 9: PrintableString 'NL1SPF002' : } : } : } 57 30: SEQUENCE { 59 13: UTCTime 13/11/2013 12:51:00 GMT 74 13: UTCTime 13/11/2014 12:51:00 GMT : } 89 20: SEQUENCE { 91 18: SET { 93 16: SEQUENCE { 95 3: OBJECT IDENTIFIER commonName (2 5 4 3) 100 9: PrintableString 'NL1SPF002' : } : } : } 111 157: SEQUENCE { 114 13: SEQUENCE { 116 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 127 0: NULL : } 129 139: BIT STRING, encapsulates { 133 135: SEQUENCE { 136 129: INTEGER : 00 C7 42 A0 7F FF A8 1F 65 A0 39 DC 63 D9 8B 09 : 7C F2 D3 59 6D 84 A6 4B 1F 05 DE 30 1B 6B FA 42 : B0 86 8C 88 75 9F A9 57 5B B2 6E E6 60 79 D7 12 : 1E 22 1B 91 18 D5 93 41 80 28 2C 4D F7 D5 46 A6 : 3E 9D 55 E1 A2 89 86 ED DC 88 9D 1B DE B8 F2 03 : 5A 56 5B 0E CB 97 3D B1 32 74 6A A8 3B 24 6C 45 : E7 1A 69 EB 2C EF D7 FD C1 4C 60 2A 6D BA 4B A3 : 34 3C D6 56 4A 3E CA 32 CD 6C 5C 47 A1 05 E6 E7 : 8D 268 1: INTEGER 3 : } : } : } 271 54: [3] { 273 52: SEQUENCE { 275 15: SEQUENCE { 277 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 282 1: BOOLEAN TRUE 285 5: OCTET STRING, encapsulates { 287 3: SEQUENCE { 289 1: BOOLEAN TRUE : } : } : } 292 11: SEQUENCE { 294 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) 299 4: OCTET STRING, encapsulates { 301 2: BIT STRING 2 unused bits : '11'B : } : } 305 20: SEQUENCE { 307 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 312 13: OCTET STRING, encapsulates { 314 11: SEQUENCE { 316 9: OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 1 11' : } : } : } : } : } : } 327 13: SEQUENCE { 329 9: OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5) 340 0: NULL : } 342 129: BIT STRING : C2 3A 8D 8E 2C A2 B5 46 7F CF 05 E2 01 38 C7 DF : 6F 6E 5F 4E E1 94 42 65 5A 67 BB 21 48 FE E1 FC : EB AB BE B2 34 65 AC 99 2E 2F 53 20 87 EC A5 0A : 14 5D 3A 08 DC 2B F2 1C 9E 46 F0 B3 E9 F9 26 FC : 6E 12 BD BF 95 4F E7 BC 11 CE 7C 22 05 B3 C7 28 : E8 E9 67 A5 05 1B A0 47 C0 E1 DC B2 D1 96 9D 46 : 90 97 66 C0 26 0F 88 90 A2 D1 6F 88 BB CB FE F4 : BB A1 90 99 AB 82 A4 87 27 95 80 27 A4 59 69 87 : } On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: The certificate is received in ASN.1 DER format. Not PEM. The only thing I want to do is verify the signature of the certificate, and thus verify the signature itself. It is self-signed so the public key in the certificate should be used to verify the signature, but it isn't working. Certificate: Data: Version: 3 (0x2) Serial Number: 3593335860 (0xd62df434) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=NL1SPF002 Validity Not Before: Nov 13 12:51:00 2013 GMT Not After : Nov 13 12:51:00 2014 GMT Subject: CN=NL1SPF002 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c7:42:a0:7f:ff:a8:1f:65:a0:39:dc:63:d9:8b: 09:7c:f2:d3:59:6d:84:a6:4b:1f:05:de:30:1b:6b: fa:42:b0:86:8c:88:75:9f:a9:57:5b:b2:6e:e6:60: 79:d7:12:1e:22:1b:91:18:d5:93:41:80:28:2c:4d: f7:d5:46:a6:3e:9d:55:e1:a2:89:86:ed:dc:88:9d: 1b:de:b8:f2:03:5a:56:5b:0e:cb:97:3d:b1:32:74: 6a:a8:3b:24:6c:45:e7:1a:69:eb:2c:ef:d7:fd:c1: 4c:60:2a:6d:ba:4b:a3:34:3c:d6:56:4a:3e:ca:32: cd:6c:5c:47:a1:05:e6:e7:8d Exponent: 3 (0x3) X509v3 extensions: X509v3 Basic Constraints: critical
Re: Verification of a x509 certificate signature
It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Adding a custom extension to a CSR
I rather not use the openssl config file, and stick with aPI's. is it really an octet string containing one ASCII character 5? no, it was just a simple example, the real values is are PRINTABLESTRING and INTEGER. Is that ehat you meant: ASN1_OCTET_STRING *os = ASN1_OCTET_STRING_new(); ASN1_OCTET_STRING_set( os, ABC test, 8 ); unsigned char *d = NULL; int dlen = i2d_ASN1_OCTET_STRING( os, d ); ASN1_OCTET_STRING os2 = ASN1_OCTET_STRING_new(); ASN1_OCTET_STRING_set( os2, d, dlen ); Cause I still gey rubbish... Is there an example of how to set such custom extension to CSR? -- View this message in context: http://openssl.6102.n7.nabble.com/Adding-a-custom-extension-to-a-CSR-tp47446p47501.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a x509 certificate signature
I want to thank everyone who replied for the help. I figured out what went wrong. Two things. The RSA public key wasn't loaded with the correct values. Thank you for giving a hint about that. The second thing was the data to verify somehow included the OID of the signature. So the second time the OID is in the file. This should've been omitted from the data, but somehow didn't Thank you all for the help. On Thu, Nov 28, 2013 at 2:26 PM, Dereck Hurtubise djhurtub...@gmail.comwrote: It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Bad OIDs (was: Re: Verification of a x509 certificate signature)
How nice, they're asking for a self-signed certificate to include a specific EKU to indicate it's a Trust Anchor, and the OID used for this has never been allocated. Crazy. I just looked at OpenSSL's objects.txt database, and found some OIDs that need some change: id-pkix-OCSP 8: extendedStatus: Extended OCSP Status should be id-pkix-ocsp-pref-sig-algs (RFC6960). id-pkix-OCSP 9: valid should be id-pkix-ocsp-extended-revoke (RFC6960). id-pkix-OCSP 10 : path id-pkix-OCSP 11 : trustRoot : Trust Root have never been defined by PKIX. RFC5906 uses a trustRoot EKU, without any OID being proposed or referenced. Your certificate includes the later one in the EKU extension. -- Erwann ABALEA Le 28/11/2013 14:26, Dereck Hurtubise a écrit : It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.info mailto:walte...@mathemainzel.info wrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org
Re: Bad OIDs (was: Re: Verification of a x509 certificate signature)
Welcome to the wonderful world of NTP Autokey. Where they misuse X509v3 extensions for their own purposes. Nothing I can do about it. It's in the specification of that RFC (5906) On Thu, Nov 28, 2013 at 4:14 PM, Erwann Abalea erwann.aba...@keynectis.comwrote: How nice, they're asking for a self-signed certificate to include a specific EKU to indicate it's a Trust Anchor, and the OID used for this has never been allocated. Crazy. I just looked at OpenSSL's objects.txt database, and found some OIDs that need some change: id-pkix-OCSP 8: extendedStatus: Extended OCSP Status should be id-pkix-ocsp-pref-sig-algs (RFC6960). id-pkix-OCSP 9: valid should be id-pkix-ocsp-extended-revoke (RFC6960). id-pkix-OCSP 10 : path id-pkix-OCSP 11 : trustRoot : Trust Root have never been defined by PKIX. RFC5906 uses a trustRoot EKU, without any OID being proposed or referenced. Your certificate includes the later one in the EKU extension. -- Erwann ABALEA Le 28/11/2013 14:26, Dereck Hurtubise a écrit : It is NTP indicating that this certificate is held by a supposed trusted root (authority). This is NTP's way of figuring out if the certificate of the subject/issuer should be trusted or not. So they misuse X509 extensions for their own purposes. This alone is not enough. So they also implement a challenge/response scheme that they do after the certificates are verified. Read RFC 5906 (autokey) on the CERT message/exchange for more information and why they do this. The Trust Root is used in the identity exchange scheme after the CERT exchange. Also in the RFC. On Thu, Nov 28, 2013 at 2:07 PM, Walter H. walte...@mathemainzel.infowrote: Hi, On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote: X509v3 Extended Key Usage: Trust Root what is this strange? 'Trust Root' as Extended Key Usage? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org