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
wrote:

>  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. 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 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. > 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

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 wrote:

> 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. 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 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 
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. 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 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 C

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