Re: Verification of a x509 certificate signature

2013-11-28 Thread Walter H.
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

2013-11-28 Thread Walter H.
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

2013-11-28 Thread Dereck Hurtubise
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

2013-11-28 Thread Danyk
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

2013-11-28 Thread Dereck Hurtubise
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)

2013-11-28 Thread Erwann Abalea
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)

2013-11-28 Thread Dereck Hurtubise
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