Re: [openssl-users] TLS handshake certificate validation options

[Thulasi Goriparthi]

Hello,

You can register a verify callback function using
X509_STORE_set_verify_cb() and X509_verify_cert() will call this
function, which can be used to by-pass targeted errors like
X509_V_ERR_INVALID_PURPOSE etc.

Check callb function from apps/x509.c


Thanks,
Thulasi.


On 16 July 2018 at 20:48, Tong  wrote:
> Dear openssl-users:
>
> We have some old certificates that have ill-formed value for the
> subjectAltName extension, causing the TLS handshake to fail.
>
> Are there any options that can be configured to by-pass the parsing of the
> subjectAltName extension (or all the x509v3 extensions) during TLS
> handshake, without disabling the certificate validation all together?
>
> Thanks for any suggestions.
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] TLS handshake certificate validation options

[Tong]

Dear openssl-users:

We have some old certificates that have ill-formed value for the
subjectAltName extension, causing the TLS handshake to fail.

Are there any options that can be configured to by-pass the parsing of the
subjectAltName extension (or all the x509v3 extensions) during TLS
handshake, without disabling the certificate validation all together?

Thanks for any suggestions.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Mitra, Rituparna (STSD)]

Hi Victor,

Thanks for the response. We are digging further into how app1 is generating the 
signature. Problem seems to be pointing more towards app1.

Regards,
Rituparna Mitra


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Viktor Dukhovni
Sent: Monday, August 04, 2014 8:51 PM
To: openssl-users@openssl.org
Subject: Re: Query on X509 certificate validation- EVP_VerifyUpdate  
EVP_VerifyFinal

On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:

 1.   app1: sends a CGI POST request to app2 ? the POST request has the UN 
 (username).
 
 2.   app2: does a CGI GET to receive the UN within app1?s POST request.
 
 3.   app2: has app1?s x509 certificate already stored, since it has to 
 allow SSO from app1 ? gets verification ctx from here.
 
 4.   app2: uses the UN (containing ! character) to form a hashdata,
 
 5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
 
 6.   app2: calls EVP_VerifyFinal -- this eventually fails during public 
 key check (EVP_PKEY_verify), due to the ! character in UN

Sorry, that's not the reason.  Your mistake is elsewhere.  In particular the 
signature is likely incorrect or signed something other than what you expected.

Also the SSO protocol design is deeply flawed.  It is not sufficient to send a 
signature of the username alone.

If the two applications are communicating directly, app1 should authenticate 
the channel with a client certificate, and can then just send the username 
unsigned in the request, since all the data sent is authenticated with app1's 
certificate.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Mitra, Rituparna (STSD)]

Hi Dave,

If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's wrong.
If you mean it passes the data *to be hashed*, that's good.

Thanks. Yes I meant the 2nd one, it passes the data to be hashed. We are 
investigating further as problem seems to be leaning towards app1.

Regards,
Rituparna Mitra


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Dave Thompson
Sent: Friday, August 08, 2014 6:28 AM
To: openssl-users@openssl.org
Subject: RE: Query on X509 certificate validation- EVP_VerifyUpdate  
EVP_VerifyFinal

 From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni
 Sent: Monday, August 04, 2014 11:21

 On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:
 
  1.   app1: sends a CGI POST request to app2 ? the POST request has
the
 UN (username). 
 
  2.   app2: does a CGI GET to receive the UN within app1?s POST
request.
 
  3.   app2: has app1?s x509 certificate already stored, since it has
to allow
 SSO from app1 ? gets verification ctx from here.
 
  4.   app2: uses the UN (containing ! character) to form a hashdata,
 
  5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
 
If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's wrong.
If you mean it passes the data *to be hashed*, that's good.

EVP_Verify{Init,Update,Final} does the hash of the data as part of verifying a 
signature just as EVP_Sign{Init,Update,Final} does the hash of the data to be 
signed.
In fact {Sign,Verify}{Init,Update} are just macros for Digest{Init,Update}, the 
PK operations are done only in Final.

  6.   app2: calls EVP_VerifyFinal -- this eventually fails during
public key
 check (EVP_PKEY_verify), due to the ! character in UN
 
snip broader points


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni
 Sent: Monday, August 04, 2014 11:21

 On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:
 
  1.   app1: sends a CGI POST request to app2 ? the POST request has
the
 UN (username). 
 
  2.   app2: does a CGI GET to receive the UN within app1?s POST
request.
 
  3.   app2: has app1?s x509 certificate already stored, since it has
to allow
 SSO from app1 ? gets verification ctx from here.
 
  4.   app2: uses the UN (containing ! character) to form a hashdata,
 
  5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
 
If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's
wrong.
If you mean it passes the data *to be hashed*, that's good.

EVP_Verify{Init,Update,Final} does the hash of the data as part of verifying
a signature 
just as EVP_Sign{Init,Update,Final} does the hash of the data to be signed.
In fact {Sign,Verify}{Init,Update} are just macros for Digest{Init,Update},
the PK operations are done only in Final.

  6.   app2: calls EVP_VerifyFinal -- this eventually fails during
public key
 check (EVP_PKEY_verify), due to the ! character in UN
 
snip broader points


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Salz, Rich]

Start by isolating the steps.  The username is in the formdata?  Can you run 
the openssl command-line program, for example, to encrypt the username you get?

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz

Re: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Viktor Dukhovni]

On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:

 1.   app1: sends a CGI POST request to app2 ? the POST request has the UN 
 (username).
 
 2.   app2: does a CGI GET to receive the UN within app1?s POST request.
 
 3.   app2: has app1?s x509 certificate already stored, since it has to 
 allow SSO from app1 ? gets verification ctx from here.
 
 4.   app2: uses the UN (containing ! character) to form a hashdata,
 
 5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
 
 6.   app2: calls EVP_VerifyFinal -- this eventually fails during public 
 key check (EVP_PKEY_verify), due to the ! character in UN

Sorry, that's not the reason.  Your mistake is elsewhere.  In
particular the signature is likely incorrect or signed something
other than what you expected.

Also the SSO protocol design is deeply flawed.  It is not sufficient
to send a signature of the username alone.

If the two applications are communicating directly, app1 should
authenticate the channel with a client certificate, and can
then just send the username unsigned in the request, since
all the data sent is authenticated with app1's certificate.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Viktor Dukhovni]

On Mon, Aug 04, 2014 at 03:21:23PM +, Viktor Dukhovni wrote:
 On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:
 
  1.   app1: sends a CGI POST request to app2 ? the POST request has the 
  UN (username).
  
  2.   app2: does a CGI GET to receive the UN within app1?s POST request.
  
  3.   app2: has app1?s x509 certificate already stored, since it has to 
  allow SSO from app1 ? gets verification ctx from here.
  
  4.   app2: uses the UN (containing ! character) to form a hashdata,
  
  5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
  
  6.   app2: calls EVP_VerifyFinal -- this eventually fails during public 
  key check (EVP_PKEY_verify), due to the ! character in UN
 
 Sorry, that's not the reason.  Your mistake is elsewhere.  In
 particular the signature is likely incorrect or signed something
 other than what you expected.

Another possibility is that the signature happens to contain a NUL
byte when the input is !test, and the code is not correctly
processing strings with embedded NUL bytes.  (Even if that is the
problem, the SSO design is still wrong).

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Mitra, Rituparna (STSD)]

Hi,

Thanks for the response.

The problem I am seeing is not with the DN. From what I understand, the 
distinguished name can be any one of the fields – CN, issuer, subject, that 
comes as part of the x509 certificate contents. None of these contain the ! 
character.

Let me clarify the issue a little more.

This is a SSO (single sign on) scenario from ‘app1’ -- ‘app2’ (our application 
is ‘app2’ while ‘app1’ is an external application not in our control)



1.   app1: sends a CGI POST request to app2 – the POST request has the UN 
(username).

2.   app2: does a CGI GET to receive the UN within app1’s POST request.

3.   app2: has app1’s x509 certificate already stored, since it has to 
allow SSO from app1 – gets verification ctx from here.

4.   app2: uses the UN (containing ! character) to form a hashdata,

5.   app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )

6.   app2: calls EVP_VerifyFinal -- this eventually fails during public key 
check (EVP_PKEY_verify), due to the ! character in UN

As you see, in app2, we are not having any control over the character string 
type of the UN.

Is there a way to fix ‘app2’ to make EVP_VerifyFinal pass ? We can’t make 
changes to ‘app1’ as the application is not owned by us.
Is there any other solution you would suggest?


Thanks,
Rituparna Mitra




From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Salz, Rich
Sent: Friday, August 01, 2014 7:33 PM
To: openssl-users@openssl.org
Subject: RE: Query on X509 certificate validation- EVP_VerifyUpdate  
EVP_VerifyFinal

You have to look at the character string type of the DN.  For example, in 
printableString the exclamation point is an illegal character.

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz


From: Mitra, Rituparna (STSD)
Sent: Friday, August 01, 2014 7:21 PM
To: openssl-users@openssl.org
Subject: Query on X509 certificate validation- EVP_VerifyUpdate  
EVP_VerifyFinal

Hi,

I am using “openssl-1.0.1h” to do X509 certificate validation for accessing 
from app1 to app2 (these are 2 separate applications).


-  In app2, I have uploaded the X509 certificate generated by app1 and 
I am using the following code segment in app2 to verify the certificate (when 
app1 tries to login to app2).

-  This code works fine for all user names, except usernames containing 
a ! symbol (exclamation).

 EVP_MD_CTX_init(ctx);
 EVP_VerifyInit(ctx, md);
 EVP_VerifyUpdate(ctx, hashdata, strlen(hashdata));
 err = EVP_VerifyFinal(ctx, x509_sig, sigsize, pkey);

 where pkey = public key retrieved from the certificate.
   hashdata is a string calculated using the username as 
follows:  system_name:domain\username: 


-  EVP_VerifyFinal()  returns success with username test.

-  But using !test fails at EVP_VerifyFinal() which returns an error 
value -- err = 0 (67702888)


Here ! seems to be the problem character since nothing else is different b/w 
the 2 cases. I am curious to know the following:


a)  Do X509 certificates treat ! character differently?

b)  Is there a way to handle usernames with a ! correctly, so that 
certificate check passes?

c)   Since hashdata is passed to EVP_VerifyUpdate(), do I need to take care 
of anything while forming “hashdata” with the username?

Any response would be greatly appreciated.

Thanks and regards,
Rituparna Mitra

Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Mitra, Rituparna (STSD)]

Hi,

I am using “openssl-1.0.1h” to do X509 certificate validation for accessing 
from app1 to app2 (these are 2 separate applications).


-  In app2, I have uploaded the X509 certificate generated by app1 and 
I am using the following code segment in app2 to verify the certificate (when 
app1 tries to login to app2).

-  This code works fine for all user names, except usernames containing 
a ! symbol (exclamation).

 EVP_MD_CTX_init(ctx);
 EVP_VerifyInit(ctx, md);
 EVP_VerifyUpdate(ctx, hashdata, strlen(hashdata));
 err = EVP_VerifyFinal(ctx, x509_sig, sigsize, pkey);

 where pkey = public key retrieved from the certificate.
   hashdata is a string calculated using the username as 
follows:  system_name:domain\username: 


-  EVP_VerifyFinal()  returns success with username test.

-  But using !test fails at EVP_VerifyFinal() which returns an error 
value -- err = 0 (67702888)


Here ! seems to be the problem character since nothing else is different b/w 
the 2 cases. I am curious to know the following:


a)  Do X509 certificates treat ! character differently?

b)  Is there a way to handle usernames with a ! correctly, so that 
certificate check passes?

c)   Since hashdata is passed to EVP_VerifyUpdate(), do I need to take care 
of anything while forming “hashdata” with the username?

Any response would be greatly appreciated.

Thanks and regards,
Rituparna Mitra

RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal

[Salz, Rich]

You have to look at the character string type of the DN.  For example, in 
printableString the exclamation point is an illegal character.

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz

Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL

[Alban D.]

Sorry for the confusion.
We initially uploaded the wrong version of the paper and that's
something I noticed yesterday.
The code was out of sync with the repo on Github. I also changed a few
other things while I was at it.
Thanks for all the feedback.

2012/10/30 Jeffrey Walton noloa...@gmail.com:
 On Mon, Oct 29, 2012 at 4:02 PM, Erwann Abalea
 erwann.aba...@keynectis.com wrote:
 Where's the failure here?
 hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization, and in
 case of a NULL hostname or certificate it is returned by the function,
 unmodified.
 My bad - you were right. I fetched the document again and some parts
 were rewritten. The re-written document did not include the function
 with HOSTNAME_VALIDATION_ERR. I'm not sure how I missed
 hostname_matched was a return variable (I think I zero'd in on the
 name, which implied a match).

 Jeff

 Le 27/10/2012 21:00, Jeffrey Walton a écrit :

 On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:

 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.

 ] int validate_hostname(char *hostname, X509 *server_cert) {
 ]   int hostname_matched = HOSTNAME_VALIDATION_ERR;
 ]   if((hostname == NULL) || (server_cert == NULL))
 ]  goto error;
 ] ...
 ]   error:
 ] return hostname_matched;
 ] }
 You failed open rather than closed. Its not a good choice of
 strategies for high integrity software.
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jakob Bohm]

On 10/29/2012 7:05 PM, Jeffrey Walton wrote:

On Mon, Oct 29, 2012 at 11:04 AM, Jakob Bohm jb-open...@wisemo.com wrote:

On 10/27/2012 10:58 PM, Jeffrey Walton wrote:


On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:


Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:

http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.



] Supporting wildcard certificates requires manually parsing
] the name to find the wildcard character, ensuring that it is
] in a valid location within the domain, and then trying to
] match the pattern with the server's expected hostname.
Don''t do it because it violates the Principal of Least Privilege. Why
should users be asked to trust the receptionist's machine in the lobby
or a developer's machine with nearly anything installed?

If you are in a multi-domain environment (such as Apache with virtual
hosts), use multiple certificates or Server Name Indication (SNI).



You obviously don't understand the proper uses and necessity of
wildcard certificates:

Actually, I do. Its not a risk I am willing to accept. As a security
architect, I am more than happy to kick software that follows the
practice.



If you truly understand the part of my post that you removed
(especially item 3), then your beliefs about its insecurity and your
insistence on blocking it on behalf of others not so deluded are pure
security theater.

I will repeat my item 3 here for reference:

 3. Being covered by a wildcard certificates name match does not give
 a computer access to the private key needed to actually use that
 certificate.  The security model is that the wildcard cert identifies
 the organization, and the organization only installs the private key
 on trusted servers

Put another way, a wildcard certificate identifies a person or 
organization, not a particular computer.  The person/org decides

which computers are trusted to represent them at the relevant level
of assurance.  It is the closest available approximation of giving
the person/org a path-constrained intermediary CA, with the path
constraint enforced for the DNS path, not the X.400 path.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Tue, Oct 30, 2012 at 10:03 AM, Jakob Bohm jb-open...@wisemo.com wrote:
 On 10/29/2012 7:05 PM, Jeffrey Walton wrote:

 On Mon, Oct 29, 2012 at 11:04 AM, Jakob Bohm jb-open...@wisemo.com
 wrote:

 On 10/27/2012 10:58 PM, Jeffrey Walton wrote:


 On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:


 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:


 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.



 ] Supporting wildcard certificates requires manually parsing
 ] the name to find the wildcard character, ensuring that it is
 ] in a valid location within the domain, and then trying to
 ] match the pattern with the server's expected hostname.
 Don''t do it because it violates the Principal of Least Privilege. Why
 should users be asked to trust the receptionist's machine in the lobby
 or a developer's machine with nearly anything installed?

 If you are in a multi-domain environment (such as Apache with virtual
 hosts), use multiple certificates or Server Name Indication (SNI).


 You obviously don't understand the proper uses and necessity of
 wildcard certificates:

 Actually, I do. Its not a risk I am willing to accept. As a security
 architect, I am more than happy to kick software that follows the
 practice.


 If you truly understand the part of my post that you removed
 (especially item 3), then your beliefs about its insecurity and your
 insistence on blocking it on behalf of others not so deluded are pure
 security theater.

 I will repeat my item 3 here for reference:


 3. Being covered by a wildcard certificates name match does not give
 a computer access to the private key needed to actually use that
 certificate.  The security model is that the wildcard cert identifies
 the organization, and the organization only installs the private key
 on trusted servers

 Put another way, a wildcard certificate identifies a person or organization,
 not a particular computer.  The person/org decides
 which computers are trusted to represent them at the relevant level
 of assurance.  It is the closest available approximation of giving
 the person/org a path-constrained intermediary CA, with the path
 constraint enforced for the DNS path, not the X.400 path.
I've been in a shop where the development team set up a game server on
a development box.The box was then put on the internet. The private
key was not in an HSM, it was ripped the filesystem of an Apaches
server.

Its not just small shops that abuse things. Diginotar's private key
was compromised too. So big shops which get audited also fail.

I really don't care how the bad guy gets the private key. I expect it to happen.

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Michel]

Thanks,

Also it can be usefull to go back to the book 'Network Security with 
OpenSSL', pages 128 to 138.


Michel.

Le 27/10/2012 17:00, Alban D. a écrit :

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.

Thanks,

Alban D.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jakob Bohm]

On 10/27/2012 10:58 PM, Jeffrey Walton wrote:

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.


] Supporting wildcard certificates requires manually parsing
] the name to find the wildcard character, ensuring that it is
] in a valid location within the domain, and then trying to
] match the pattern with the server's expected hostname.
Don''t do it because it violates the Principal of Least Privilege. Why
should users be asked to trust the receptionist's machine in the lobby
or a developer's machine with nearly anything installed?

If you are in a multi-domain environment (such as Apache with virtual
hosts), use multiple certificates or Server Name Indication (SNI).



You obviously don't understand the proper uses and necessity of
wildcard certificates:

1. Many existing clients support no form of SNI (there are two forms
for HTTP) or use protocols that will have difficulty supporting it.

2. The business model of commercial CAs make it economically
infeasible for sites to acquire separate certificates for each low
visibility service, such as enabling STARTTLS on SMTP to a backup MX.
But acquiring a wildcard cert shared by all such services is
affordable and does not require a purchase bureaucracy every time an
additional server is brought online.

3. Being covered by a wildcard certificates name match does not give
a computer access to the private key needed to actually use that
certificate.  The security model is that the wildcard cert identifies
the organization, and the organization only installs the private key
on trusted servers.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Mon, Oct 29, 2012 at 11:04 AM, Jakob Bohm jb-open...@wisemo.com wrote:
 On 10/27/2012 10:58 PM, Jeffrey Walton wrote:

 On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:

 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.


 ] Supporting wildcard certificates requires manually parsing
 ] the name to find the wildcard character, ensuring that it is
 ] in a valid location within the domain, and then trying to
 ] match the pattern with the server's expected hostname.
 Don''t do it because it violates the Principal of Least Privilege. Why
 should users be asked to trust the receptionist's machine in the lobby
 or a developer's machine with nearly anything installed?

 If you are in a multi-domain environment (such as Apache with virtual
 hosts), use multiple certificates or Server Name Indication (SNI).


 You obviously don't understand the proper uses and necessity of
 wildcard certificates:
Actually, I do. Its not a risk I am willing to accept. As a security
architect, I am more than happy to kick software that follows the
practice.

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL

[Erwann Abalea]

Where's the failure here?
hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization, 
and in case of a NULL hostname or certificate it is returned by the 
function, unmodified.


--
Erwann ABALEA

Le 27/10/2012 21:00, Jeffrey Walton a écrit :

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.

] int validate_hostname(char *hostname, X509 *server_cert) {
]   int hostname_matched = HOSTNAME_VALIDATION_ERR;
]   if((hostname == NULL) || (server_cert == NULL))
]  goto error;
] ...
]   error:
] return hostname_matched;
] }
You failed open rather than closed. Its not a good choice of
strategies for high integrity software.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Reference material on how to do certificate validation with OpenSSL

[Erwann Abalea]

Bonjour,

In the 4.2 paragraph, talking about revocation, you explicitely write 
that your code examples don't check for revocation. Depending on your 
target audience, this might not be a wise choice.
In the same part, you're referring to a post by Ben Laurie about how 
hard it is to detect revoked certificates, and thus how useless it is 
to revoke a certificate, because applications don't check for 
revocation, or do it with a soft-fail behavior. That's something public 
CAs want to be changed, and the lack of revocation check in your 
examples won't help.


--
Erwann ABALEA

Le 27/10/2012 17:00, Alban D. a écrit :

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.

Thanks,

Alban D.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Mon, Oct 29, 2012 at 4:02 PM, Erwann Abalea
erwann.aba...@keynectis.com wrote:
 Where's the failure here?
 hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization, and in
 case of a NULL hostname or certificate it is returned by the function,
 unmodified.
HOSTNAME_VALIDATION_ERR is not mentioned in
https://github.com/iSECPartners/ssl-conservatory/raw/master/everything-you-wanted-to-know-about-openssl.pdf.

Jeff

 Le 27/10/2012 21:00, Jeffrey Walton a écrit :

 On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:

 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.

 ] int validate_hostname(char *hostname, X509 *server_cert) {
 ]   int hostname_matched = HOSTNAME_VALIDATION_ERR;
 ]   if((hostname == NULL) || (server_cert == NULL))
 ]  goto error;
 ] ...
 ]   error:
 ] return hostname_matched;
 ] }
 You failed open rather than closed. Its not a good choice of
 strategies for high integrity software.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Mon, Oct 29, 2012 at 4:02 PM, Erwann Abalea
erwann.aba...@keynectis.com wrote:
 Where's the failure here?
 hostname_matched is set to HOSTNAME_VALIDATION_ERR at initialization, and in
 case of a NULL hostname or certificate it is returned by the function,
 unmodified.
My bad - you were right. I fetched the document again and some parts
were rewritten. The re-written document did not include the function
with HOSTNAME_VALIDATION_ERR. I'm not sure how I missed
hostname_matched was a return variable (I think I zero'd in on the
name, which implied a match).

Jeff

 Le 27/10/2012 21:00, Jeffrey Walton a écrit :

 On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:

 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:

 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.

 ] int validate_hostname(char *hostname, X509 *server_cert) {
 ]   int hostname_matched = HOSTNAME_VALIDATION_ERR;
 ]   if((hostname == NULL) || (server_cert == NULL))
 ]  goto error;
 ] ...
 ]   error:
 ] return hostname_matched;
 ] }
 You failed open rather than closed. Its not a good choice of
 strategies for high integrity software.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Reference material on how to do certificate validation with OpenSSL

[Alban D.]

Hi everyone,

iSEC Partners just released a paper that provides detailed guidelines
and sample code on how to properly do certificate validation with
OpenSSL:
http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

It is not trivial and so I thought this reference material could be
useful to people on this mailing list.

Thanks,

Alban D.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:
 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:
 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.

] Most applications only have to connect to one or a few application
] servers. Therefore, the trust store should only contain the CA
] certificates needed to connect to those servers. Restricting the list
] of trusted CA certificate in such way is a security practice called
] certificate pinning.

I don't believe this is correct. One does not pin a CA's certificate
when using SSL/TLS (and VPN) with a Public CA Hierarchy. Suppose you
are pinning a CA that gets compromised. The bad guy can the (1)
generate spurious certificate for a legitimate site, and (2) sign with
the compromised CA. Your program would accept the site's certificates
as valid. Or suppose a CA decides to issue a Subordinate CA to allow
SSL/TLS traffic interception. Again, your program would chose to
accept. We've already seen these things happen with Diginotar
(http://en.wikipedia.org/wiki/DigiNotar) and Trustwave
(http://blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html
and https://bugzilla.mozilla.org/show_bug.cgi?id=724929).).

When discussing pinning with a public ca hierarchy, one pins either
(1) the host's public key, or (2) the host's X509 certificate. Pinning
a host's public key is nearly the same as StrictHostKeyChecking in
SSH. Note: Google rotates its certificates regularly, but does not
rotate its public keys. So you would definetly wnt to pin public keys
(rather than certificates) for encrypted.google.com, gmail.com, etc.

Pinning the public key (or certificate) leverages the pre-exsiting
relationship to identify the host in question (this is all about
identity).

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:
 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:
 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.
] Applications that need to be able to connect to any server on
] the Internet (such as browsers) could instead rely on Mozilla's
] list of root certificates used in Firefox.

Mozilla cannot be trusted. When Trustwave issued a Subordinate CA to
perform traffic interception on sites not under the operator's
control, Mozilla rewarded their bad behavior by continuing their
inclusion in the Root CA list.
(http://blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html
and https://bugzilla.mozilla.org/show_bug.cgi?id=724929).
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:
 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:
 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.
] int validate_hostname(char *hostname, X509 *server_cert) {
]   int hostname_matched = HOSTNAME_VALIDATION_ERR;
]   if((hostname == NULL) || (server_cert == NULL))
]  goto error;
] ...
]   error:
] return hostname_matched;
] }
You failed open rather than closed. Its not a good choice of
strategies for high integrity software.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Peter Sylvester]

The way how common names are verified in

The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software

is not correct.
It gives a false match when there is more than one common name ava
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Reference material on how to do certificate validation with OpenSSL

[Jeffrey Walton]

On Sat, Oct 27, 2012 at 11:00 AM, Alban D. blan...@gmail.com wrote:
 Hi everyone,

 iSEC Partners just released a paper that provides detailed guidelines
 and sample code on how to properly do certificate validation with
 OpenSSL:
 http://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-tls-validation.html

 It is not trivial and so I thought this reference material could be
 useful to people on this mailing list.

] Supporting wildcard certificates requires manually parsing
] the name to find the wildcard character, ensuring that it is
] in a valid location within the domain, and then trying to
] match the pattern with the server's expected hostname.
Don''t do it because it violates the Principal of Least Privilege. Why
should users be asked to trust the receptionist's machine in the lobby
or a developer's machine with nearly anything installed?

If you are in a multi-domain environment (such as Apache with virtual
hosts), use multiple certificates or Server Name Indication (SNI).

Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Erwann Abalea]

Le 25/09/2012 18:45, Jakob Bohm a écrit :

On 9/25/2012 6:12 PM, Erwann Abalea wrote:

Le 25/09/2012 14:16, Jakob Bohm a écrit :
 On 9/25/2012 11:11 AM, Erwann Abalea wrote:

[...]

Any signature algorithm works by dividing the universe of N bit strings
into those that are validsignatures for the object and those that are
not.  For most algorithms the valid subset is exactly one of the 2**N
bit strings, for some ECC variants it is two of them, for DSA it is
2**(N/2) of them. [...]


I'll have to re-read this in a quiet environment, with my HAC kept 
close. Thanks.


[...]

So there's one more possibility: the CA changes its key, keeps its name
(so it's the same CA), and issues 2 certificates. First one is a
self-signed one with its brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).


So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself.  Very weird, unless
there are appropriate key identifiers in thecertificates.


That's right. And that's precisely a self-issued certificate, considered 
differently on the validation algorithm. For example, such a certificate 
doesn't count for the pathLen constraints.

{subject,authority}KeyIdentifier extensions are not mandatory.

Consider a root CA with a self-signed certificate, with only 
digitalSignature set in its keyUsage extension. This CA can then 
self-issue another certificate with the cRLSign bit set. That's 
different from a CA with 2 self-signed certificates, each one for one 
usage. The former is valid for RFC5280 while the latter isn't, both are 
valid for X.509.


[hours later]
Another scenario has been used in real world: have the root certificate 
contain the hash of the public key of the next root (etc), the subject 
name doesn't change. That was used for SET (shortly, I admit), as all CA 
certificates were renewed every year. Some kind of forward chaining.



 Some of the discussions on this thread seems to indicate that when
 both the
 A and B certificate are available, OpenSSL sometimes may fail to stop
 when
 it hits the new (A) CA in the trust store because it does not
 distinguish between
 its trust store and its collection of cached/preloaded intermediary
 certificates
 (unlike Windows, which has seperate stores for those two categories).

What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.


I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time 
now).


The OP talked about www.google.com, I connected and got a 1024bits 
intermediate Thawte certificate from 2004, signed by VeriSign C3.


--
Erwann ABALEA

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Erwann Abalea]

Bonjour,

Le 24/09/2012 21:03, Jakob Bohm a écrit :

Does that work with any other serious X.509 validation toolkit?


It should.
When trying to build a valid certification path, all possibilities have 
to be tested until one of them succeeds. If a CA gives a good signature, 
but fails for whatever reason (a non respected constraint, a revoked 
state, or an expired certificate), then the considered certificate chain 
is invalid, and the next has to be tested.


To make this work (assuming the old root CA cert has not yet expired), 
the validation code will need to actually verify the End Entity

certificate against both public keys, which effectively reduces the
algorithm security by allowing twice as many bit strings to be
accepted as valid.


An EE can be valid under different certificate chains, without reducing 
the security of anything. Think about cross-certifications.



As for trust anchor update scenarios, I know of 3 different scenarios
that should be accepted by any good X.509 validation algorithm:

1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.


This needs a manual update of the trust store, as you're introducing a 
new certificate object not linked to anything.
Following X509 rules, you can also change the key. Following RFC5280 
ones, you can't (in fact, you can, but it won't be the root of the same 
PKI).



2. Changing the CA key when the old key has *not* been compromised.
Here the CA generates a new key and issues two certificates for it:

   A. A self-signed new root with a serial number or other variation
 in one of the subject name components.


This is a change in the name of the CA, whence it's a completely 
different CA.



   B. A certificate for the new key and the same subject and (optional)
 SubjectKeyIdentifier as A, but issued by the old root certificate
 identity and key.


That's a self-issued certificate, it's OK until the old CA certificate 
is not expired. Well described in X.509.
Manual update of the trust anchor is still necessary if you want the 
validation to pass the expiration date of the old CA cert.



3. Setting up the CA to have keys for more than one algorithm (such
as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
certificate validation could SHOULD (but might not) match issued end
entity certificates to the trust anchor by also comparing 
signatureAlgorithm in the issued certificate against 
subjectPublicKeyInfo.algorithm in the candidate issuer cert from the

store.


The issued certificate will have sha1withRSA or sha256withRSA in its 
signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096.
A SHA256 certificate (or however you call it) can still produce 
sha1withRSA signatures. The other way is also possible, of course.


--
Erwann ABALEA

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Klaus Darilion]

Just for the records: my workaround was to check the expiration date 
while dumping the certificates into the file, and skipping the expired 
ones. Further, I dump the certificates once a day to avoid issues with 
certificates expired after doing the dump.


regards
Klaus

On 13.09.2012 17:09, Erik Tkal wrote:

I suppose that’s a workaround, but doesn’t address the root cause.
Windows can quite happily handle expired certificates still hanging out
in trusted stores; I see this all the time as root updates occur and
renewed certificates are installed.  It seems that a change in OpenSSL
broke the previous behaviour that allowed this as well, though we can’t
tell if it’s the s_client app or the OpenSSL cert store functionality
that changed this.



*Erik Tkal**
*Juniper OAC/UAC/Pulse Development

*From:*owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
*Sent:* Thursday, September 13, 2012 9:42 AM
*To:* openssl-users@openssl.org
*Subject:* RE: certificate validation issues with openssl 1.0.0 and
expired certificates in cafile

Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.

/Charles/

*From:*owner-openssl-us...@openssl.org
mailto:owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Ashok C
*Sent:* Thursday, September 13, 2012 12:49 AM
*To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
*Subject:* Re: certificate validation issues with openssl 1.0.0 and
expired certificates in cafile

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok

On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com
mailto:ash@gmail.com wrote:

Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion
klaus.mailingli...@pernau.at mailto:klaus.mailingli...@pernau.at wrote:

Hi!

I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google
and validate its certificate:

openssl s_client -connect www.google.com:443 http://www.google.com:443
-CAfile dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation
fails with:
   Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
http://www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority

When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for
Verisign with identical subject, whereas one is expired, the other not.

X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Subject Public Key Algorithm: RSA

X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
 Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate
and searches if there is another valid one whereas openssl 1.0.0 stop
with the first expired certificate.

Is the new behavior the intended behavior? Is it possible to have the
old behavior also in new openssl versions?

Thanks
Klaus

__
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


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl

Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Jakob Bohm]

On 9/25/2012 11:11 AM, Erwann Abalea wrote:

Bonjour,

Le 24/09/2012 21:03, Jakob Bohm a écrit :
 Does that work with any other serious X.509 validation toolkit?

It should.
When trying to build a valid certification path, all possibilities have
to be tested until one of them succeeds. If a CA gives a good signature,
but fails for whatever reason (a non respected constraint, a revoked
state, or an expired certificate), then the considered certificate chain
is invalid, and the next has to be tested.

Read carefully, I said that if the only way to pick the right candidate 
is to

validate the signature against 2 same-algorithm public keys, then the
security of the signature validation is reduced by up to log2(keycount) 
bits.


Anything that can be filtered out without signature checking (such as
different algorithms, different key identifies, different key lengths etc.)
does not cause that problem. And is OK security wise, but may not
be implemented by all (otherwise compliant) X.509 implementations.


 To make this work (assuming the old root CA cert has not yet expired),
 the validation code will need to actually verify the End Entity
 certificate against both public keys, which effectively reduces the
 algorithm security by allowing twice as many bit strings to be
 accepted as valid.

An EE can be valid under different certificate chains, without reducing
the security of anything. Think about cross-certifications.

Cross-certifications involve different distinguished names for signature
chain building, these can all be verified by building the trusted chain
before validating the signatures.


 As for trust anchor update scenarios, I know of 3 different scenarios
 that should be accepted by any good X.509 validation algorithm:

 1. Changing expiry or other attributes while keeping the key.
 Here the CA issues a new self-signed certificate with updated
 attributes but unchanged key.

This needs a manual update of the trust store, as you're introducing a
new certificate object not linked to anything.
Following X509 rules, you can also change the key. Following RFC5280
ones, you can't (in fact, you can, but it won't be the root of the same
PKI).

Yes, but the trick is that it provides a transitional period (between 
issuing

the new self-signed CA cert and expiry or other limits of the old cert
attributes kicking in) during which the issued certificates are fully valid
against either cert, thus allowing time to update multiple trust stores
across a network (small or world-wide).

 2. Changing the CA key when the old key has *not* been compromised.
 Here the CA generates a new key and issues two certificates for it:

A. A self-signed new root with a serial number or other variation
  in one of the subject name components.

This is a change in the name of the CA, whence it's a completely
different CA.

Yes, but it will still have a sufficiently close name to retain any 
reputation

based human trust.

B. A certificate for the new key and the same subject and (optional)
  SubjectKeyIdentifier as A, but issued by the old root certificate
  identity and key.

That's a self-issued certificate, it's OK until the old CA certificate
is not expired. Well described in X.509.
Manual update of the trust anchor is still necessary if you want the
validation to pass the expiration date of the old CA cert.


Actually, this is a cross-certificate from the old CA to the new CA.
as you said, well described in the literature.

Some of the discussions on this thread seems to indicate that when both the
A and B certificate are available, OpenSSL sometimes may fail to stop when
it hits the new (A) CA in the trust store because it does not 
distinguish between
its trust store and its collection of cached/preloaded intermediary 
certificates

(unlike Windows, which has seperate stores for those two categories).

 3. Setting up the CA to have keys for more than one algorithm (such
 as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
 certificate validation could SHOULD (but might not) match issued end
 entity certificates to the trust anchor by also comparing
 signatureAlgorithm in the issued certificate against
 subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
 store.

The issued certificate will have sha1withRSA or sha256withRSA in its
signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096.
I deliberately did not give the OID names for the combinations, just 
descriptions,

that is why I wrote it as multiple space separated words.

A SHA256 certificate (or however you call it) can still produce
sha1withRSA signatures. The other way is also possible, of course.


Yes, but it cannot be validated by an X.509 implementation which does not
support SHA256 because of a silly policy to never add new algorithms in
updates to older versions, even if thousands of library clients cannot be
easily updated to a new library version (this bad policy is in both the
OpenSSL project

Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Erwann Abalea]

).  In this case, the
 certificate validation could SHOULD (but might not) match issued end
 entity certificates to the trust anchor by also comparing
 signatureAlgorithm in the issued certificate against
 subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
 store.

The issued certificate will have sha1withRSA or sha256withRSA in its
signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096.
I deliberately did not give the OID names for the combinations, just 
descriptions,

that is why I wrote it as multiple space separated words.


Yes. And the signatureAlgorithm in the issued certificate will show 
sha1withRSA while the subjectPublicKeyInfo.algorithm in the different 
candidates issuer certificates will all have rsaEncryption. The 
combination of these 2 elements alone can't be a distinguisher. In this 
scenario, key lengths and signature lengths could be used as 
distinguishers, but the implementation then needs to parse the innards 
of the certificates.



Think of the regular posts on
this list from people asking if they can upgrade Apache to OpenSSL 1.0.1
without recompiling their existing Apache httpd binaries.  Then think 
of all

the users who refuse to switch from Windows XP to Windows Vista/7/8
because they like the old OS better, and who then suffer from Microsoft
not adding SHA-256 to the crypto algorithms in the XP core. And then 
throw

in the knock on effect on anyone trying to communicate with everybody,
including those hapless victims of SHA-256 refusal.


True. They may have good reasons for not upgrading. (I doubt it)


I am on the list, no need to cc me


Sorry, that's the default reply to all behavior from Thunderbird.

--
Erwann ABALEA



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Jakob Bohm]

 brand new key. Second one is a self-issued one,
signed by the previous key.
Both this case and the previous one are used by several countries for
CSCA certificates (for passports).


So you say they have an intermediary certificate where
Issuer DN==Subject DN,
but the Issuer keyis not the key in the cert itself.  Very weird, unless
there are appropriate key identifiers in thecertificates.

 Some of the discussions on this thread seems to indicate that when
 both the
 A and B certificate are available, OpenSSL sometimes may fail to stop
 when
 it hits the new (A) CA in the trust store because it does not
 distinguish between
 its trust store and its collection of cached/preloaded intermediary
 certificates
 (unlike Windows, which has seperate stores for those two categories).

What I understand from the OP seems to be different from this paragraph.
I grabed the old 1996-2004 VeriSign C3 root certificate, and its renewed
version 1996-2028 (same key, same name). That's your scenario 1.
The Thawte CA certificate doesn't have any authorityKeyIdentifier
extension, and OpenSSL correctly tests each possible certificate,
filtered by their subject name, until the validation is OK.


I assume the Thawte certificate you mention is not the same as the
VeriSign certificate (they havebeen the same company for a long time now).

The example I was referring to was GeoTrust (another VeriSign company)
and their Equifax cross cert.


  3. Setting up the CA to have keys for more than one algorithm (such
  as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
  certificate validation could SHOULD (but might not) match issued end
  entity certificates to the trust anchor by also comparing
  signatureAlgorithm in the issued certificate against
  subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
  store.

 The issued certificate will have sha1withRSA or sha256withRSA 
in its

 signatureAlgorithm, not sha1withRSA1024 or sha256withRSA4096.
 I deliberately did not give the OID names for the combinations, just
 descriptions,
 that is why I wrote it as multiple space separated words.

Yes. And the signatureAlgorithm in the issued certificate will show
sha1withRSA while the subjectPublicKeyInfo.algorithm in the different
candidates issuer certificates will all have rsaEncryption. The
combination of these 2 elements alone can't be a distinguisher. In this
scenario, key lengths and signature lengths could be used as
distinguishers, but the implementation then needs to parse the innards
of the certificates.

 Think of the regular posts on
 this list from people asking if they can upgrade Apache to OpenSSL 1.0.1
 without recompiling their existing Apache httpd binaries.  Then think
 of all
 the users who refuse to switch from Windows XP to Windows Vista/7/8
 because they like the old OS better, and who then suffer from Microsoft
 not adding SHA-256 to the crypto algorithms in the XP core. And then
 throw
 in the knock on effect on anyone trying to communicate with everybody,
 including those hapless victims of SHA-256 refusal.

True. They may have good reasons for not upgrading. (I doubt it)

Top reasons for users wanting to keep XP as long as possible:

1. Less bloat than in Vista and later.

2. Hardware not big enough to run Vista and later.

3. Needed line of business applications not compatible with Vista and
 later.


 I am on the list, no need to cc me

Sorry, that's the default reply to all behavior from Thunderbird.


Try Reply or Reply List (depending on version).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Jakob Bohm]

On 9/13/2012 3:41 PM, Charles Mills wrote:

Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.

/Charles/




Windows has built in support for using and checking time stamping 
countersignatures in PKCS7 signatures.  If the countersignature is 
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its 
certificate is checked as if the current time was the one certified

by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).

Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).

P.S.

I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.

The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 
1.2.840.113549.1.9.6 = counterSignature

unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute).  The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.

On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:

POST url with Accept: application/octet-string Content-Type: 
application/octet-string The post data is Base64 of DER of

   SEQUENCE { -- Attribute
  type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
  SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
 content Type OID -- must be 1.2.840.113549.1.7.1 =data
 content [0] EXPLICIT OCTET STRING
-- must be the outer encryptedDigest
 }
  }
}

Response if successful is a 200 HTTP status with Content-Type: 
application/octet-string and a value which is Base64 of DER of

a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)

This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi,

One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.

--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 /Charles/



 Windows has built in support for using and checking time stamping
 countersignatures in PKCS7 signatures.  If the countersignature is signed
 with a currently valid certificate with the time stamping
 extended usage enabled, then the outer PKCS7 signature and its certificate
 is checked as if the current time was the one certified
 by the time stamp (but still using up to date revocation
 information, paying attention to revocation reasons and dates).

 Thus the Windows certificate store has good reason to keep around
 expired CA certificates going back to ca. 1996 (when Microsoft
 released the first version supporting time stamped signatures).

 P.S.

 I see no technical reason why such time stamp countersignature
 support could not be added to the OpenSSL core code.

 The validation side implementation involves a few standard OIDs
 (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 1.2.840.113549.1.9.6
 = counterSignature
 unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
 authenticated attribute).  The countersignature specifies the
 signed data type to be 1.2.840.113549.1.7.1=data, but the
 signed data is really the encryptedDigest/signatureValue from
 the enclosing SignerInfo being countersigned (as per
 PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
 a counterSignature made by an entity with the timeStamping
 extended key usage is simply the standard signingTime
 authenticated attribute in the counterSignature itself.

 On the signing side, the signer simply submits his
 encryptedDigest/signatureValue to a time stamping service he has
 a contract with, using a simplified historic protocol as follows:

 POST url with Accept: application/octet-string Content-Type:
 application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
   type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
   SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
  content Type OID -- must be 1.2.840.113549.1.7.1 =data
  content [0] EXPLICIT OCTET STRING
 -- must be the outer encryptedDigest
  }
   }
 }

 Response if successful is a 200 HTTP status with Content-Type:
 application/octet-string and a value which is Base64 of DER of
 a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
 from the request. The time is indicated by the standard
 signingTime authenticated attribute in the only SignerInfo in
 signerInfos)

 This historic time stamping protocol is necessary because the
 RFC3161 protocol returns a signature which is not a valid RFC2985
 counterSignature.

 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 WiseMo - Remote Service Management for PCs, Phones and Embedded


 __**__**__
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Jakob Bohm]

Hi,

In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?

P.S.

Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.

For the benefit of other readers:

I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.

On 9/24/2012 6:26 PM, Ashok C wrote:

Hi,

One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem with the
newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or SKI 
fields.


--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com
mailto:jb-open...@wisemo.com wrote:

On 9/13/2012 3:41 PM, Charles Mills wrote:

Would it make sense to delete the expired certificate from the
Windows
store? Duplicate expired/non expired CA certificates sounds to
me like a
problem waiting to happen.

/Charles/



Windows has built in support for using and checking time stamping
countersignatures in PKCS7 signatures.  If the countersignature is
signed with a currently valid certificate with the time stamping
extended usage enabled, then the outer PKCS7 signature and its
certificate is checked as if the current time was the one certified
by the time stamp (but still using up to date revocation
information, paying attention to revocation reasons and dates).

Thus the Windows certificate store has good reason to keep around
expired CA certificates going back to ca. 1996 (when Microsoft
released the first version supporting time stamped signatures).

P.S.

I see no technical reason why such time stamp countersignature
support could not be added to the OpenSSL core code.

The validation side implementation involves a few standard OIDs
(1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
1.2.840.113549.1.9.6 = counterSignature
unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
authenticated attribute).  The countersignature specifies the
signed data type to be 1.2.840.113549.1.7.1=data, but the
signed data is really the encryptedDigest/signatureValue from
the enclosing SignerInfo being countersigned (as per
PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
a counterSignature made by an entity with the timeStamping
extended key usage is simply the standard signingTime
authenticated attribute in the counterSignature itself.

On the signing side, the signer simply submits his
encryptedDigest/signatureValue to a time stamping service he has
a contract with, using a simplified historic protocol as follows:

POST url with Accept: application/octet-string Content-Type:
application/octet-string The post data is Base64 of DER of
SEQUENCE { -- Attribute
   type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
   SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
  content Type OID -- must be 1.2.840.113549.1.7.1 =data
  content [0] EXPLICIT OCTET STRING
 -- must be the outer encryptedDigest
  }
   }
 }

Response if successful is a 200 HTTP status with Content-Type:
application/octet-string and a value which is Base64 of DER of
a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
from the request. The time is indicated by the standard
signingTime authenticated attribute in the only SignerInfo in
signerInfos)

This historic time stamping protocol is necessary because the
RFC3161 protocol returns a signature which is not a valid RFC2985
counterSignature.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
tel:%2B45%2031%2013%2016%2010
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



__

OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
   

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..

Ashok
On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com wrote:

 Hi,

 In your test case which fields actually differ between the
 old root CA certificate and the new root CA certificate?

 P.S.

 Please do not use those 3 letter abbreviations of certificate
 field names, very few people know those abbreviations.

 For the benefit of other readers:

 I think Ashok was referring to AuthorityKeyIdentifier and
 SubjectKeyIdentifier fieldsbeing absent from the root
 CA certificates in his scenario.

 On 9/24/2012 6:26 PM, Ashok C wrote:

 Hi,

 One more observation was made here in another test case.
 _*Configuration:*_
 One old root CA certificate oldca.pem with subject name say, C=IN
 One new root CA certificate newca.pem with same subject name.
 One EE certificate, ee.pem issued by new root CA.

 _*Test case 1:*_
 Using CAFile option in openssl verify of the ee.pem,
 If oldca.pem is placed on top and newca.pem below, verification fails.
 i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

 _*Test case 2:*_
 If newca.pem is placed on top and oldca.pem below that, verification
 succeeds.
 i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

 Test case 1 does not seem to correct behaviour as the trust store
 contains newca.pem. Ideally the lookup needs to verify ee.pem with the
 newca.pem.

 P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
 fields.

 --
 Ashok


 On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm jb-open...@wisemo.com
 mailto:jb-open...@wisemo.com** wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate from the
 Windows
 store? Duplicate expired/non expired CA certificates sounds to
 me like a
 problem waiting to happen.

 /Charles/



 Windows has built in support for using and checking time stamping
 countersignatures in PKCS7 signatures.  If the countersignature is
 signed with a currently valid certificate with the time stamping
 extended usage enabled, then the outer PKCS7 signature and its
 certificate is checked as if the current time was the one certified
 by the time stamp (but still using up to date revocation
 information, paying attention to revocation reasons and dates).

 Thus the Windows certificate store has good reason to keep around
 expired CA certificates going back to ca. 1996 (when Microsoft
 released the first version supporting time stamped signatures).

 P.S.

 I see no technical reason why such time stamp countersignature
 support could not be added to the OpenSSL core code.

 The validation side implementation involves a few standard OIDs
 (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
 1.2.840.113549.1.9.6 = counterSignature
 unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
 authenticated attribute).  The countersignature specifies the
 signed data type to be 1.2.840.113549.1.7.1=data, but the
 signed data is really the encryptedDigest/signatureValue from
 the enclosing SignerInfo being countersigned (as per
 PKCS#9/RFC2985 section 5.3.6).  The timeStamp indicated by
 a counterSignature made by an entity with the timeStamping
 extended key usage is simply the standard signingTime
 authenticated attribute in the counterSignature itself.

 On the signing side, the signer simply submits his
 encryptedDigest/signatureValue to a time stamping service he has
 a contract with, using a simplified historic protocol as follows:

 POST url with Accept: application/octet-string Content-Type:
 application/octet-string The post data is Base64 of DER of
 SEQUENCE { -- Attribute
type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
   content Type OID -- must be 1.2.840.113549.1.7.1 =data
   content [0] EXPLICIT OCTET STRING
  -- must be the outer encryptedDigest
   }
}
  }

 Response if successful is a 200 HTTP status with Content-Type:
 application/octet-string and a value which is Base64 of DER of
 a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
 from the request. The time is indicated by the standard
 signingTime authenticated attribute in the only SignerInfo in
 signerInfos)

 This historic time stamping protocol is necessary because the
 RFC3161 protocol returns a signature which is not a valid RFC2985
 counterSignature.

 Enjoy

 Jakob
 --
 Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
 

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Jakob Bohm]

Does that work with any other serious X.509 validation toolkit?

To make this work (assuming the old root CA cert has not yet expired), 
the validation code will need to actually verify the End Entity

certificate against both public keys, which effectively reduces the
algorithm security by allowing twice as many bit strings to be
accepted as valid.

Filtering based on criteria that do not involve actual signature
validation would be cryptographically safe, but when falling back to
validating against multiple signatures, extra care is needed for the
above reason.

As for trust anchor update scenarios, I know of 3 different scenarios
that should be accepted by any good X.509 validation algorithm:

1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.

2. Changing the CA key when the old key has *not* been compromised.
Here the CA generates a new key and issues two certificates for it:

   A. A self-signed new root with a serial number or other variation
 in one of the subject name components.
   B. A certificate for the new key and the same subject and (optional)
 SubjectKeyIdentifier as A, but issued by the old root certificate
 identity and key.

End Entities with certificates issued with the new key reference the
modified subject as authority and should be configured to supply the
transitional B certificate in chains sent to other end entities.
Such end entities should then succeed validating against either the
old root CA (via the B certificate supplied) or the new root CA
(via finding it as a locally configured trust anchor).

This is the scenario used by at least one major CA for its upgrade
to larger keys, and SSL servers that forget the B certificate in
the supplied chain get rejected by at least one common platform
version (Android 2.3) because it only includes the old trust
root in its store and uses an underdocumented BouncyCastly store
format thus preventing the efficient deployment of the new A cert.

3. Setting up the CA to have keys for more than one algorithm (such
as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
certificate validation could SHOULD (but might not) match issued end
entity certificates to the trust anchor by also comparing 
signatureAlgorithm in the issued certificate against 
subjectPublicKeyInfo.algorithm in the candidate issuer cert from the

store.

However because not all clients are going to do that, it is still
recommended that the CA follows the scenario 2 procedures, except
when it is a test CA for verifying handling of this scenario in
X.509 implementations.

On 9/24/2012 8:01 PM, Ashok C wrote:

Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..

Ashok

On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com
mailto:jb-open...@wisemo.com wrote:

Hi,

In your test case which fields actually differ between the
old root CA certificate and the new root CA certificate?

P.S.

Please do not use those 3 letter abbreviations of certificate
field names, very few people know those abbreviations.

For the benefit of other readers:

I think Ashok was referring to AuthorityKeyIdentifier and
SubjectKeyIdentifier fieldsbeing absent from the root
CA certificates in his scenario.

On 9/24/2012 6:26 PM, Ashok C wrote:

Hi,

One more observation was made here in another test case.
_*Configuration:*_
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.

_*Test case 1:*_
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification
fails.
i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

_*Test case 2:*_
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

Test case 1 does not seem to correct behaviour as the trust store
contains newca.pem. Ideally the lookup needs to verify ee.pem
with the
newca.pem.

P.S. The CA and EE certificates are v3 but do not contain AKI or
SKI fields.

--
Ashok


On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm
jb-open...@wisemo.com mailto:jb-open...@wisemo.com
mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com__
wrote:

 On 9/13/2012 3:41 PM, Charles Mills wrote:

 Would it make sense to delete the expired certificate
from the
 Windows

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Thanks Jacob, but in the three scenarios you mentioned, the first one *does
not* seem to be supported by openssl 1.0.0*. I think that was the subject
of this email thread in the beginning.

1. Changing expiry or other attributes while keeping the key.
Here the CA issues a new self-signed certificate with updated
attributes but unchanged key.

Here, if the expired one is encountered first, openSSL does not lookup the
non-expired CA certificate. This is then a bug right?

--
Ashok



On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm jb-open...@wisemo.com wrote:

 Does that work with any other serious X.509 validation toolkit?

 To make this work (assuming the old root CA cert has not yet expired), the
 validation code will need to actually verify the End Entity
 certificate against both public keys, which effectively reduces the
 algorithm security by allowing twice as many bit strings to be
 accepted as valid.

 Filtering based on criteria that do not involve actual signature
 validation would be cryptographically safe, but when falling back to
 validating against multiple signatures, extra care is needed for the
 above reason.

 As for trust anchor update scenarios, I know of 3 different scenarios
 that should be accepted by any good X.509 validation algorithm:

 1. Changing expiry or other attributes while keeping the key.
 Here the CA issues a new self-signed certificate with updated
 attributes but unchanged key.

 2. Changing the CA key when the old key has *not* been compromised.
 Here the CA generates a new key and issues two certificates for it:

A. A self-signed new root with a serial number or other variation
  in one of the subject name components.
B. A certificate for the new key and the same subject and (optional)
  SubjectKeyIdentifier as A, but issued by the old root certificate
  identity and key.

 End Entities with certificates issued with the new key reference the
 modified subject as authority and should be configured to supply the
 transitional B certificate in chains sent to other end entities.
 Such end entities should then succeed validating against either the
 old root CA (via the B certificate supplied) or the new root CA
 (via finding it as a locally configured trust anchor).

 This is the scenario used by at least one major CA for its upgrade
 to larger keys, and SSL servers that forget the B certificate in
 the supplied chain get rejected by at least one common platform
 version (Android 2.3) because it only includes the old trust
 root in its store and uses an underdocumented BouncyCastly store
 format thus preventing the efficient deployment of the new A cert.

 3. Setting up the CA to have keys for more than one algorithm (such
 as RSA 1024 with SHA1 and RSA 4096 with SHA256).  In this case, the
 certificate validation could SHOULD (but might not) match issued end
 entity certificates to the trust anchor by also comparing
 signatureAlgorithm in the issued certificate against
 subjectPublicKeyInfo.algorithm in the candidate issuer cert from the
 store.

 However because not all clients are going to do that, it is still
 recommended that the CA follows the scenario 2 procedures, except
 when it is a test CA for verifying handling of this scenario in
 X.509 implementations.


 On 9/24/2012 8:01 PM, Ashok C wrote:

 Only the private and public keys are different.. Rest of the fields are
 same.. Basically I am simulating the trust anchor update related
 scenarios..
 And yes Jacob, thanks for indicating, I'll make sure I don't use such
 abbreviations from here on..

 Ashok

 On Sep 24, 2012 11:25 PM, Jakob Bohm jb-open...@wisemo.com
 mailto:jb-open...@wisemo.com** wrote:

 Hi,

 In your test case which fields actually differ between the
 old root CA certificate and the new root CA certificate?

 P.S.

 Please do not use those 3 letter abbreviations of certificate
 field names, very few people know those abbreviations.

 For the benefit of other readers:

 I think Ashok was referring to AuthorityKeyIdentifier and
 SubjectKeyIdentifier fieldsbeing absent from the root
 CA certificates in his scenario.

 On 9/24/2012 6:26 PM, Ashok C wrote:

 Hi,

 One more observation was made here in another test case.
 _*Configuration:*_
 One old root CA certificate oldca.pem with subject name say, C=IN
 One new root CA certificate newca.pem with same subject name.
 One EE certificate, ee.pem issued by new root CA.

 _*Test case 1:*_
 Using CAFile option in openssl verify of the ee.pem,
 If oldca.pem is placed on top and newca.pem below, verification
 fails.
 i.e., cat oldca.pem  combined.pem;cat newca.pem  combined.pem

 _*Test case 2:*_
 If newca.pem is placed on top and oldca.pem below that,
 verification
 succeeds.
 i.e., cat newca.pem  combined.pem; cat oldca.pemcombined.pem

 Test case 1 does not seem

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Gentle reminder ..
Just want to know if this is a bug or intended behaviour.

--
Ashok

On Fri, Sep 14, 2012 at 3:12 PM, Ashok C ash@gmail.com wrote:

 Hi Etkal,

 s_client app or the OpenSSL cert store functionality that changed this.
 The problem is with the openSSL store itself, as I had tested this with my
 own SSL client and observed the same behaviour.

 --
 Ashok

 On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote:

 I suppose that’s a workaround, but doesn’t address the root cause.
 Windows can quite happily handle expired certificates still hanging out in
 trusted stores; I see this all the time as root updates occur and renewed
 certificates are installed.  It seems that a change in OpenSSL broke the
 previous behaviour that allowed this as well, though we can’t tell if it’s
 the s_client app or the OpenSSL cert store functionality that changed this.
 


 
 *Erik Tkal**
 *Juniper OAC/UAC/Pulse Development

 

 ** **

 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
 *Sent:* Thursday, September 13, 2012 9:42 AM
 *To:* openssl-users@openssl.org
 *Subject:* RE: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 ** **

 *Charles*

 *From:* owner-openssl-us...@openssl.org [
 mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org]
 *On Behalf Of *Ashok C
 *Sent:* Thursday, September 13, 2012 12:49 AM
 *To:* openssl-users@openssl.org
 *Subject:* Re: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Sending again as the previous email did not appear in list.
 Is there some problem with the mailing list?

 --
 Ashok

 On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok

 ** **

 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 Hi!

 I wrote a small program which dumps all root certificates from Windows
 certificate store into a file. Then I use openssl to connect to Google and
 validate its certificate:

 openssl s_client -connect www.google.com:443 -CAfile dump.crt

 When using openssl0.9.8k or openssl0.9.8x everything works as expected.

 When using openssl1.0.0g or openssl 1.0.1c the certificate validation
 fails with:
   Verify return code: 10 (certificate has expired)

 CONNECTED(016C)
 depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
 Certification Authority
 verify error:num=10:certificate has expired
 notAfter=Jan  7 23:59:59 2004 GMT
 verify return:0
 ---
 Certificate chain
  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
 Authority

 When analyzing the cafile with the dumped certificates from Windows
 certificate store, I found out that there are two certificates for Verisign
 with identical subject, whereas one is expired, the other not.

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA


 Thus, it seems that openssl 0.9.8 just ignores the expired certificate
 and searches if there is another valid one whereas openssl 1.0.0 stop with
 the first expired certificate.

 Is the new behavior the intended behavior? Is it possible to have the old
 behavior also in new openssl versions?

 Thanks
 Klaus

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org***
 *

 ** **

 ** **

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi Etkal,

s_client app or the OpenSSL cert store functionality that changed this.
The problem is with the openSSL store itself, as I had tested this with my
own SSL client and observed the same behaviour.

--
Ashok

On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal et...@juniper.net wrote:

 I suppose that’s a workaround, but doesn’t address the root cause.
 Windows can quite happily handle expired certificates still hanging out in
 trusted stores; I see this all the time as root updates occur and renewed
 certificates are installed.  It seems that a change in OpenSSL broke the
 previous behaviour that allowed this as well, though we can’t tell if it’s
 the s_client app or the OpenSSL cert store functionality that changed this.
 


 
 *Erik Tkal**
 *Juniper OAC/UAC/Pulse Development

 

 ** **

 *From:* owner-openssl-us...@openssl.org [mailto:
 owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills
 *Sent:* Thursday, September 13, 2012 9:42 AM
 *To:* openssl-users@openssl.org
 *Subject:* RE: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Would it make sense to delete the expired certificate from the Windows
 store? Duplicate expired/non expired CA certificates sounds to me like a
 problem waiting to happen.

 ** **

 *Charles*

 *From:* owner-openssl-us...@openssl.org [
 mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org]
 *On Behalf Of *Ashok C
 *Sent:* Thursday, September 13, 2012 12:49 AM
 *To:* openssl-users@openssl.org
 *Subject:* Re: certificate validation issues with openssl 1.0.0 and
 expired certificates in cafile

 ** **

 Sending again as the previous email did not appear in list.
 Is there some problem with the mailing list?

 --
 Ashok

 On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok

 ** **

 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 Hi!

 I wrote a small program which dumps all root certificates from Windows
 certificate store into a file. Then I use openssl to connect to Google and
 validate its certificate:

 openssl s_client -connect www.google.com:443 -CAfile dump.crt

 When using openssl0.9.8k or openssl0.9.8x everything works as expected.

 When using openssl1.0.0g or openssl 1.0.1c the certificate validation
 fails with:
   Verify return code: 10 (certificate has expired)

 CONNECTED(016C)
 depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
 Certification Authority
 verify error:num=10:certificate has expired
 notAfter=Jan  7 23:59:59 2004 GMT
 verify return:0
 ---
 Certificate chain
  0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
 Authority

 When analyzing the cafile with the dumped certificates from Windows
 certificate store, I found out that there are two certificates for Verisign
 with identical subject, whereas one is expired, the other not.

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA


 Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
 searches if there is another valid one whereas openssl 1.0.0 stop with the
 first expired certificate.

 Is the new behavior the intended behavior? Is it possible to have the old
 behavior also in new openssl versions?

 Thanks
 Klaus

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

 ** **

 ** **

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok

On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

 Hi,

 I don't think this question was answered. Could you please reply?

 --
 Ashok


 On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
 klaus.mailingli...@pernau.at wrote:

 Hi!

 I wrote a small program which dumps all root certificates from Windows
 certificate store into a file. Then I use openssl to connect to Google and
 validate its certificate:

 openssl s_client -connect www.google.com:443 -CAfile dump.crt

 When using openssl0.9.8k or openssl0.9.8x everything works as expected.

 When using openssl1.0.0g or openssl 1.0.1c the certificate validation
 fails with:
   Verify return code: 10 (certificate has expired)

 CONNECTED(016C)
 depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
 Certification Authority
 verify error:num=10:certificate has expired
 notAfter=Jan  7 23:59:59 2004 GMT
 verify return:0
 ---
 Certificate chain
  0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
 Authority

 When analyzing the cafile with the dumped certificates from Windows
 certificate store, I found out that there are two certificates for Verisign
 with identical subject, whereas one is expired, the other not.

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA


 Thus, it seems that openssl 0.9.8 just ignores the expired certificate
 and searches if there is another valid one whereas openssl 1.0.0 stop with
 the first expired certificate.

 Is the new behavior the intended behavior? Is it possible to have the old
 behavior also in new openssl versions?

 Thanks
 Klaus

 __**__**
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Charles Mills]

Would it make sense to delete the expired certificate from the Windows
store? Duplicate expired/non expired CA certificates sounds to me like a
problem waiting to happen.

 

Charles

From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Ashok C
Sent: Thursday, September 13, 2012 12:49 AM
To: openssl-users@openssl.org
Subject: Re: certificate validation issues with openssl 1.0.0 and expired
certificates in cafile

 

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok

On Wed, Sep 12, 2012 at 2:59 PM, Ashok C ash@gmail.com wrote:

Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

 

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion
klaus.mailingli...@pernau.at wrote:

Hi!

I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google and
validate its certificate:

openssl s_client -connect www.google.com:443 -CAfile dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails
with:
  Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority

When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for Verisign
with identical subject, whereas one is expired, the other not.

X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA

X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
searches if there is another valid one whereas openssl 1.0.0 stop with the
first expired certificate.

Is the new behavior the intended behavior? Is it possible to have the old
behavior also in new openssl versions?

Thanks
Klaus

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

 

 

RE: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Erik Tkal]

I suppose that's a workaround, but doesn't address the root cause.  Windows can 
quite happily handle expired certificates still hanging out in trusted stores; 
I see this all the time as root updates occur and renewed certificates are 
installed.  It seems that a change in OpenSSL broke the previous behaviour that 
allowed this as well, though we can't tell if it's the s_client app or the 
OpenSSL cert store functionality that changed this.


Erik Tkal
Juniper OAC/UAC/Pulse Development


From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Charles Mills
Sent: Thursday, September 13, 2012 9:42 AM
To: openssl-users@openssl.org
Subject: RE: certificate validation issues with openssl 1.0.0 and expired 
certificates in cafile

Would it make sense to delete the expired certificate from the Windows store? 
Duplicate expired/non expired CA certificates sounds to me like a problem 
waiting to happen.

Charles
From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org 
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Ashok C
Sent: Thursday, September 13, 2012 12:49 AM
To: openssl-users@openssl.orgmailto:openssl-users@openssl.org
Subject: Re: certificate validation issues with openssl 1.0.0 and expired 
certificates in cafile

Sending again as the previous email did not appear in list.
Is there some problem with the mailing list?

--
Ashok
On Wed, Sep 12, 2012 at 2:59 PM, Ashok C 
ash@gmail.commailto:ash@gmail.com wrote:
Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
klaus.mailingli...@pernau.atmailto:klaus.mailingli...@pernau.at wrote:
Hi!

I wrote a small program which dumps all root certificates from Windows 
certificate store into a file. Then I use openssl to connect to Google and 
validate its certificate:

openssl s_client -connect www.google.com:443http://www.google.com:443 -CAfile 
dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails 
with:
  Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary Certification 
Authority
verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google 
Inc/CN=www.google.comhttp://www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

When analyzing the cafile with the dumped certificates from Windows certificate 
store, I found out that there are two certificates for Verisign with identical 
subject, whereas one is expired, the other not.

X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification 
Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification 
Authority
Subject Public Key Algorithm: RSA

X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification 
Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification 
Authority
Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate and 
searches if there is another valid one whereas openssl 1.0.0 stop with the 
first expired certificate.

Is the new behavior the intended behavior? Is it possible to have the old 
behavior also in new openssl versions?

Thanks
Klaus

__
OpenSSL Project http://www.openssl.org
User Support Mailing List
openssl-users@openssl.orgmailto:openssl-users@openssl.org
Automated List Manager   
majord...@openssl.orgmailto:majord...@openssl.org

Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Ashok C]

Hi,

I don't think this question was answered. Could you please reply?

--
Ashok

On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion 
klaus.mailingli...@pernau.at wrote:

 Hi!

 I wrote a small program which dumps all root certificates from Windows
 certificate store into a file. Then I use openssl to connect to Google and
 validate its certificate:

 openssl s_client -connect www.google.com:443 -CAfile dump.crt

 When using openssl0.9.8k or openssl0.9.8x everything works as expected.

 When using openssl1.0.0g or openssl 1.0.1c the certificate validation
 fails with:
   Verify return code: 10 (certificate has expired)

 CONNECTED(016C)
 depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary
 Certification Authority
 verify error:num=10:certificate has expired
 notAfter=Jan  7 23:59:59 2004 GMT
 verify return:0
 ---
 Certificate chain
  0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
  1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
 Authority

 When analyzing the cafile with the dumped certificates from Windows
 certificate store, I found out that there are two certificates for Verisign
 with identical subject, whereas one is expired, the other not.

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Wed Jan 07 23:59:59 UTC 2004
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA

 X.509 Certificate Information:
 Version: 1
 Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf
 Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Validity:
 Not Before: Mon Jan 29 00:00:00 UTC 1996
 Not After: Tue Aug 01 23:59:59 UTC 2028
 Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
 Certification Authority
 Subject Public Key Algorithm: RSA


 Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
 searches if there is another valid one whereas openssl 1.0.0 stop with the
 first expired certificate.

 Is the new behavior the intended behavior? Is it possible to have the old
 behavior also in new openssl versions?

 Thanks
 Klaus

 __**__**__
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

certificate validation issues with openssl 1.0.0 and expired certificates in cafile

[Klaus Darilion]

Hi!

I wrote a small program which dumps all root certificates from Windows 
certificate store into a file. Then I use openssl to connect to Google 
and validate its certificate:


openssl s_client -connect www.google.com:443 -CAfile dump.crt

When using openssl0.9.8k or openssl0.9.8x everything works as expected.

When using openssl1.0.0g or openssl 1.0.1c the certificate validation 
fails with:

  Verify return code: 10 (certificate has expired)

CONNECTED(016C)
depth=2 C = US, O = VeriSign, Inc., OU = Class 3 Public Primary 
Certification Authority

verify error:num=10:certificate has expired
notAfter=Jan  7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification 
Authority


When analyzing the cafile with the dumped certificates from Windows 
certificate store, I found out that there are two certificates for 
Verisign with identical subject, whereas one is expired, the other not.


X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Subject Public Key Algorithm: RSA

X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary 
Certification Authority

Subject Public Key Algorithm: RSA


Thus, it seems that openssl 0.9.8 just ignores the expired certificate 
and searches if there is another valid one whereas openssl 1.0.0 stop 
with the first expired certificate.


Is the new behavior the intended behavior? Is it possible to have the 
old behavior also in new openssl versions?


Thanks
Klaus

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Please Help: Certificate Validation using subjectAltName extension

[Mr.Rout]

Thanks Dave for explanation.
One doubt regarding sentence  If a subjectAltName extension of type dNSName
is present, that MUST
be used as the identity(RFC 2818)

What does this line means ?

Does it says if a certificate have different CN in issuer  subject field
but SubAltname: x.x.x.x which matches with HOST.URL (server) then will
handshake goes through ?


i.e. 


[ certificate_extensions ]
basicConstraints = CA:false
subjectAltName = DNS:x.x.x.x DNS:localhost

[ req_distinguished_name ]
countryName= US
stateOrProvinceName= Chems
localityName   = Washington
organizationName   = Sercomm
commonName = Verisign

[ req_extensions ]
basicConstraints = CA:true
subjectAltName = DNS:x.x.x.x,DNS:localhost

Am i correct ?

Please help.

Best Regards,
 S  S rout

-- 
View this message in context: 
http://old.nabble.com/Please-Help%3A-Certificate-Validation-using-subjectAltName-extension-tp32906983p33873612.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: Please Help: Certificate Validation using subjectAltName extension

[Dave Thompson]

 From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout
 Sent: Saturday, 03 December, 2011 02:56

 My TLS client can validate both CN and SN  i need to test both the
 scenario.
 
 I don't know how to create certificate with subjectAltName 
 extension using openssl commands.
 
 In the RFC-2818 , there are two ways of Certificate 
 Validation for Host name
 1)CN (Common Name)
 2)SN( Subject Name)

1. Common Name part of subject name which is the value of Subject.
2. Subject *Alternative* Name which is an extension.

 If a subjectAltName extension of type dNSName is present, that MUST
 be used as the identity. Otherwise, the (most specific) Common Name
 field in the Subject field of the certificate MUST be used. Although
 the use of the Common Name is existing practice, it is deprecated and
 Certification Authorities are encouraged to use the dNSName instead.
   
As this says, although a bit tersely.

 I created Self-signed certificate  using open-ssl commands and my
 certificate chain looks like below where CN=10.204.4.69
   openssl genrsa -des3 -out server.key 1024
   openssl req -new -key server.key -out server.csr
   openssl x509 -req -days 365 -in server.csr 
 -signkey server.key -out server.crt

 Please tell how to create certificate with subjectAltName 
 extension using openssl commands ?

The same way(s) you create a cert with any extension(s).
See man req; man x509; man ca; man x509v3_config 

In x509 -req supply -extfile with the name of a config file, 
and -extsect with the name of a section in that file 
unless it is default or pointed to by default.extensions,
specifying the extension(s) you want. You want something like
subjectAltName=DNS:my.host.example

For selfsigned you can save a step (or two) with req -x509 (and 
-newkey) in which case use -extensions or req.x509_extensions .


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Please Help: Certificate Validation using subjectAltName extension

[Mr.Rout]

Dear All,

My TLS client can validate both CN and SN  i need to test both the
scenario.

I don't know how to create certificate with “subjectAltName extension” 
using openssl commands.

In the RFC-2818 , there are two ways of Certificate Validation for Host name
1)  CN (Common Name)
2)  SN( Subject Name)
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.
  
I created Self-signed certificate  using open-ssl commands and my
certificate chain looks like below where CN=10.204.4.69
  openssl genrsa -des3 -out server.key 1024
  openssl req -new -key server.key -out server.csr
  openssl x509 -req -days 365 -in server.csr -signkey server.key
-out server.crt

My Certificate chain
===
 0 s:/C=IN/ST=Karnataka/L=Bangalore/O=Home
Inc/OU=TLS/CN=10.204.4.69/emailAddress=ssr...@www.https.com
   i:/C=IN/ST=Karnataka/L=Bangalore/O=Home
Inc/OU=TLS/CN=10.204.4.69/emailAddress=ssr...@www.https.com

Please tell how to create certificate with “subjectAltName extension”  using
openssl commands ?

Thanks  in advance.
Regards,
Rout

-- 
View this message in context: 
http://old.nabble.com/Please-Help%3A-Certificate-Validation-using-subjectAltName-extension-tp32906983p32906983.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

Certificate validation failed

[Vladimir Nicolici]

We are currently implementing file time stamping for our
invoices and we are using a time stamping service that implements
RFC3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol
(TSP), over HTTP.

 

Three days ago I started looking at the openssl as a
possible solution for a TSP client. It wasn't a smooth ride, not by a
long shot.

 

First, by default, openssl doesn't include support for
time stamping, and you have to compile it from sources with a TS patch
applied.

 

But the last patch was for version 0.9.8c  and it is
almost 3 years old. So, I downloaded, 0.9.8c sources, patched them,
compiled them, and then I was able to use openssl ts to generate a sign
request.

 

But when I tried to use tsget to send the request to the
time stamping service, all hell broke loose.

 

First, I tried to run it, and I received a lot of errors
like:

 

Bareword CURLOPT_VERBOSE not allowed while strict subs in use at
./tsget line 43.

Bareword CURLOPT_FAILONERROR not allowed while strict subs in use at
./tsget line 44.

Bareword CURLOPT_USERAGENT not allowed while strict subs in use at
./tsget line 45.

Bareword CURLOPT_UPLOAD not allowed while strict subs in use at
./tsget line 48.

 

So I had to remove the use strict; line from the
script. I tried again, but I received this error:

 

Undefined subroutine WWW::Curl::easy::new called at ./tsget line 39.

 

The problem is that it should use WWW::Curl::Easy, not
WWW::Curl::easy. So I had to replace easy with Easy everywhere in the
file.

 

After trying again, I received this error:

 

/root/test.tsq: fatal error: could not get timestamp, http code: 400,
curl code: 22 (The requested URL returned error: 400)

 

After using tcpdump and Wireshark to figure out what was wrong, I found
out that curl has the questionable habit of using Expect: 100-continue
headers in the HTTP post requests, a header that is not implemented, or
not implemented properly by many HTTP servers.

 

So I had to disable the 100-continue header by adding an empty Expect:
 header, like this:

 

$curl-setopt(CURLOPT_HTTPHEADER,

[Content-Type: application/timestamp-query,

Accept: application/timestamp-reply,

Expect: ]);

 

Finally, I was able to get a response from the TS server.

 

Now, all that was left was to validate the response against the
certificate of the TS service. However, it didn't work, I received this
error trying to validate it:

 

Verification: FAILED

12855:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer
certificate not found:pk7_smime.c:365:

 

I googled it, all I could found were some references to UTF-8 in the
certificate, but it didn't seem to be the case for me. Then I tried to
use gdb (and I really hate command line debuggers), to determine what
was wrong. But by default openssl is not compiled with debugging symbols
so I had to recompile it. But I couldn't find how to compile it with
debugging support.

 

./config --help doesn't tell you what the options mean, and anyway the
-d option was not documented. I found it in the INSTALL file. But it
didn't work:

 

Operating system: x86_64-whatever-linux2

This system (debug-linux-x86_64) is not supported. See file INSTALL for
details.

 

But I just came from the INSTALL file, and it only said:

 

 On some systems, you can include debugging information as follows:

 

   $ ./config -d [options]

 

But it didn't tell me how can I include debugging
information on OTHER systems.

 

After googling about an hour, I found another not
documented option: -g . This worked.

 

But only with gdb, I wasn't able to find what is going on. Then I tried
to use emacs as a front-end to GDB, but the GDB-UI didn't work properly.
Then I tried download and compile a more recent version of emacs, but it
refused to compile on my system.

 

Then I installed Eclipse to use it as a debugger. After a few hours of
tweaking Eclipse settings, I was able to set breakpoints and do step by
step execution through the PKCS7_get0_signers function.

 

I wasn't able to find much either. The debugger jumped like crazy up and
down when during step by step execution, and it didn't display the
values of some variables, but apparently the function is called with the
p7 parameter referencing a object, the certs parameter is null, and the
flags set to 0. Then X509_find_by_issuer_and_serial (p7-d.sign-cert,
ias-issuer,  ias-serial) returns null, causing the error.

 

I was starting to think that there is a problem with the certificate
even though MS Windows thinks the certificate is OK after adding it to
the Trusted Root Certification Authorities, so I tried to validate it
with openssl verify, and I received this errors:

 

/root/tsa.cer: /CN=certSIGN Test TimeStamping Authority

error 32 at 0 depth 

Certificate validation

[Gerald Iakobinyi-Pich]

Hello all,

I am new to OpenSSL, and now I am confrontd with some problems. First
would be the following: let's assume I have a certificate (X509) which
has been issued by an CA. How is it possible to validate the
certificate through the CA (I mean establish a connection to the CA,
and let the CA do the actual validation). Can OpenSSL do this
automatically, when I call X509_verify_cert for example ?

Thanks,
Gerald
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Certificate validation

[Patrick Patterson]

On January 20, 2009 09:57:03 am Gerald Iakobinyi-Pich wrote:
 Hello all,

 I am new to OpenSSL, and now I am confrontd with some problems. First
 would be the following: let's assume I have a certificate (X509) which
 has been issued by an CA. How is it possible to validate the
 certificate through the CA (I mean establish a connection to the CA,
 and let the CA do the actual validation). Can OpenSSL do this
 automatically, when I call X509_verify_cert for example ?

What you are talking about is called SCVP (Server-based Certificate Validation 
Protocol), where a client delegates validation of the certificate to some 
other trusted entity. It doesn't have to be the CA, but could be any trusted 
party that is able to perform validations on behalf of a client.

That I know of, OpenSSL doesn't have any support for SCVP, although you could 
use OpenSSL and a good networking library to write an SCVP client and 
responder. 

However, because of the way that you formulated your question, I think that 
you may have some misunderstandings about the trust models that a PKI is 
designed to solve. I would suggest reading up on PKI in general, and then, 
and only then, try and solve your problem.

Have fun.

-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [squid-users] TR: [Bulk] Re: [squid-users] Certificate Validation problem due to Sha 256 message digest

[Kyle Hamilton]

I can't speak for SHA256 in OpenSSL, so I can't help a huge amount on
that score.  But I can tell you, regarding the root and client key
sizes...

Many software apps won't handle roots with keys greater than 4096 bits
(older ones choke on anything above 2048).  There is at least one
class of devices (Cisco ipsec VPN concentrators) that won't work with
anything over 1024 bits up the entire chain, including the root.

Also, NIST recommends that 1024-bit keys be retired within the next 2 years.

-Kyle H

On Mon, Dec 15, 2008 at 2:58 AM, Raphael jr...@jraph.com wrote:
 Hi Henrik,

 Thanks for helping.

 I'm checking for calling OpenSSL_add_all_algorithms() in the sources.
 Concerning the ciphers, I don't know either, but all the certificates were
 issued using Openssl (and OpenCA 1.0.2)

 I chose to issue a CA certificate with 8192 bits length, may it become a
 problem ?
 The certificates are 2048 bits long, here is an example:

 Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FR, O=x, OU=CA, CN=CA/emailaddress=rese...@x.fr
Validity
Not Before: Oct 29 09:54:00 2008 GMT
Not After : Dec  7 09:54:00 2035 GMT
Subject: C=FR, O=CAHPP, OU=Users, CN=72571934AA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b8:19:f7:08:a8:24:2e:f2:77:fc:cf:49:fb:2a:
...
58:50:87:52:2d:2b:43:98:f7:2f:99:6f:43:e7:be:
23:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection, Microsoft
 Smartcardlogin
Netscape Comment:
User Certificate of X
X509v3 Subject Key Identifier:
34:03:0A:FB:37:C7:F0:59:16:1D:84:85:FC:18:BA:4C:31:1A:25:E8
X509v3 Authority Key Identifier:

 keyid:A6:30:F5:FA:A3:88:27:C5:D7:91:AE:91:D4:75:09:28:41:85:D4:C2

 DirName:/C=FR/O=x/OU=CA/CN=CA/emailaddress=rese...@x.fr
serial:F8:DA:53:89:72:B7:DC:B1

X509v3 Subject Alternative Name:
email:rese...@x.fr
X509v3 Issuer Alternative Name:
email:rese...@x.fr
Netscape CA Revocation Url:
https://ldap.x.fr/openca2/pub/crl/cacrl.crl
Netscape Revocation Url:
https://ldap.x.fr/openca2/pub/crl/cacrl.crl
X509v3 CRL Distribution Points:
URI:https://ldap.x.fr/openca2/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption
9d:c6:ef:97:97:4f:ae:23:4c:a2:46:12:83:aa:0a:c8:b9:4a:
...
38:42:35:1f:63:69:0b:ed:08:01:56:a7:14:aa:3f:5f

 May it help ?
 Raphael

 -Message d'origine-
 De : Henrik Nordstrom [mailto:hen...@henriknordstrom.net]
 Envoyé : dimanche 14 décembre 2008 00:23
 À : Raphael
 Cc : squid-us...@squid-cache.org
 Objet : Re: [squid-users] TR: [Bulk] Re: [squid-users] Certificate
 Validation problem due to Sha 256 message digest

 On Fri, 2008-12-12 at 14:53 +0100, Raphael wrote:

 I use Openssl 0.9.8i which manages to check the certificate. I am also
 able
 to get the sha256 digest of a file :
 openssl dgst -sha256 /root/openssl-0.9.8i.tar.gz
 is working and giving me the message digest.

 That's fine. But the digest algoritm also needs to be in the cipher
 suite profile. In the normal openssl cipher suite for SSL only SHA1 is
 included.

 I don't know if OpenSSL supports SHA2 in the cipher suites. It does not
 look like it from a quick glance (see openssl ciphers command). (0.9.8g)

 Regards
 Henrik


 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

RE: [squid-users] TR: [Bulk] Re: [squid-users] Certificate Validation problem due to Sha 256 message digest

[Raphael]

Hi Henrik,

Thanks for helping. 

I'm checking for calling OpenSSL_add_all_algorithms() in the sources.
Concerning the ciphers, I don't know either, but all the certificates were
issued using Openssl (and OpenCA 1.0.2)

I chose to issue a CA certificate with 8192 bits length, may it become a
problem ?
The certificates are 2048 bits long, here is an example:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FR, O=x, OU=CA, CN=CA/emailaddress=rese...@x.fr
Validity
Not Before: Oct 29 09:54:00 2008 GMT
Not After : Dec  7 09:54:00 2035 GMT
Subject: C=FR, O=CAHPP, OU=Users, CN=72571934AA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b8:19:f7:08:a8:24:2e:f2:77:fc:cf:49:fb:2a:
...
58:50:87:52:2d:2b:43:98:f7:2f:99:6f:43:e7:be:
23:b5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Client, S/MIME
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, E-mail Protection, Microsoft
Smartcardlogin
Netscape Comment:
User Certificate of X
X509v3 Subject Key Identifier:
34:03:0A:FB:37:C7:F0:59:16:1D:84:85:FC:18:BA:4C:31:1A:25:E8
X509v3 Authority Key Identifier:
 
keyid:A6:30:F5:FA:A3:88:27:C5:D7:91:AE:91:D4:75:09:28:41:85:D4:C2
 
DirName:/C=FR/O=x/OU=CA/CN=CA/emailaddress=rese...@x.fr
serial:F8:DA:53:89:72:B7:DC:B1

X509v3 Subject Alternative Name:
email:rese...@x.fr
X509v3 Issuer Alternative Name:
email:rese...@x.fr
Netscape CA Revocation Url:
https://ldap.x.fr/openca2/pub/crl/cacrl.crl
Netscape Revocation Url:
https://ldap.x.fr/openca2/pub/crl/cacrl.crl
X509v3 CRL Distribution Points:
URI:https://ldap.x.fr/openca2/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption
9d:c6:ef:97:97:4f:ae:23:4c:a2:46:12:83:aa:0a:c8:b9:4a:
...
38:42:35:1f:63:69:0b:ed:08:01:56:a7:14:aa:3f:5f

May it help ?
Raphael

-Message d'origine-
De : Henrik Nordstrom [mailto:hen...@henriknordstrom.net] 
Envoyé : dimanche 14 décembre 2008 00:23
À : Raphael
Cc : squid-us...@squid-cache.org
Objet : Re: [squid-users] TR: [Bulk] Re: [squid-users] Certificate
Validation problem due to Sha 256 message digest

On Fri, 2008-12-12 at 14:53 +0100, Raphael wrote:

 I use Openssl 0.9.8i which manages to check the certificate. I am also
able
 to get the sha256 digest of a file :
 openssl dgst -sha256 /root/openssl-0.9.8i.tar.gz
 is working and giving me the message digest.

That's fine. But the digest algoritm also needs to be in the cipher
suite profile. In the normal openssl cipher suite for SSL only SHA1 is
included.

I don't know if OpenSSL supports SHA2 in the cipher suites. It does not
look like it from a quick glance (see openssl ciphers command). (0.9.8g)

Regards
Henrik


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Certificate validation problem

[Gerhard Gappmeier]

Thanks Dave,

today I rechecked the dump of the certificates which cause the problem.
The AUTHORITY_KEYID was really missing in them.
They were created using some MS .Net stuff.
My certificates which I create with openssl work fine.

I told the guy who created the wrong certificates about the missing field.
In our protocol this field is mandatory because our commonNames are not always 
unique.

On Friday 10 October 2008 02:03:44 Dave Thompson wrote:
  -Original Message-
  From: [EMAIL PROTECTED] On Behalf Of Gerhard Gappmeier
  Sent: Wednesday, 08 October, 2008 08:14
 
  I've a problem with validating self-signed certificates.
 
  In my use case it's possible (but unlikely) to have multiple self-signed
  certificates with the same commonName.

 More to the point, they are root CA certs -- selfsigned, AND used to sign
 child certs. Your problem is with child linkage, not selfsigned as such.

  In the used protocol the URI field in subjectAltName fulfills the
  purpose of distinguishing the application instances.

 That appears to be irrelevant.

  When validating a certificate using X509_verify_cert it seems that
  OpenSSL finds the wrong certificate in the store
  due to the same commonName and then the validation fails.
 
  As far as I understood the code - but I'm not sure - the problem is,
  that X509_check_issued() that is called indirectly by
  find_issuer() doesn't check the certificate serial number when searching
  for the issuer certificate
  and only looks for the commonName.
  This happens because no AUTHORITY_KEYID (subject-akid) is available in
  the subject structure. (why?)
  See the screenshot for details.

 Your screenshot came out totally illegible, at least for me.

 AKID is an optional extension, with several optional subformats.
 Do you have a copy (e.g. in a file) of the cert you want to validate
 i.e. the subject=child cert? If so, check the extension is present,
 and has (child.)AKID.keyid = parent.subjkeyid
 and/or (child.)AKID.(issuer+serial) = parent.(issuer+serial) .

 How did you obtain, or create, the child cert? (Commercial CA,
 inhouse CA, openssl CA.pl, openssl commandline, etc.)

  The certificate of course has a serial number so I want this to be
  checked when looking up a certificate in the store.

 Which cert? When you want to look up the parent you need attributes
 of the parent, not the child.  If you want to look up the parent
 by issuer+serial (serial alone is not enough) (although in this case
 parent is selfsigned so its issuer and subject are the same),
 use child.AKID.(issuer+serial) as above.



 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]

RE: Certificate validation problem

[Dave Thompson]

 -Original Message-
 From: [EMAIL PROTECTED] On Behalf Of Gerhard Gappmeier
 Sent: Wednesday, 08 October, 2008 08:14

 I've a problem with validating self-signed certificates.
 
 In my use case it's possible (but unlikely) to have multiple self-signed
 certificates with the same commonName.

More to the point, they are root CA certs -- selfsigned, AND used to sign 
child certs. Your problem is with child linkage, not selfsigned as such.

 In the used protocol the URI field in subjectAltName fulfills the
 purpose of distinguishing the application instances.
 
That appears to be irrelevant.

 When validating a certificate using X509_verify_cert it seems that
 OpenSSL finds the wrong certificate in the store
 due to the same commonName and then the validation fails.
 
 As far as I understood the code - but I'm not sure - the problem is,
 that X509_check_issued() that is called indirectly by
 find_issuer() doesn't check the certificate serial number when searching
 for the issuer certificate
 and only looks for the commonName.
 This happens because no AUTHORITY_KEYID (subject-akid) is available in
 the subject structure. (why?)
 See the screenshot for details.
 
Your screenshot came out totally illegible, at least for me.

AKID is an optional extension, with several optional subformats. 
Do you have a copy (e.g. in a file) of the cert you want to validate 
i.e. the subject=child cert? If so, check the extension is present,
and has (child.)AKID.keyid = parent.subjkeyid
and/or (child.)AKID.(issuer+serial) = parent.(issuer+serial) .

How did you obtain, or create, the child cert? (Commercial CA, 
inhouse CA, openssl CA.pl, openssl commandline, etc.)

 The certificate of course has a serial number so I want this to be
 checked when looking up a certificate in the store.

Which cert? When you want to look up the parent you need attributes 
of the parent, not the child.  If you want to look up the parent 
by issuer+serial (serial alone is not enough) (although in this case 
parent is selfsigned so its issuer and subject are the same), 
use child.AKID.(issuer+serial) as above.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: The rules of SSL-Certificate validation?

[Lutz Jaenicke]

Anri Lau wrote:
 Hi Luzt,

 On 18/04/2008, *Lutz Jaenicke* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 Anri Lau wrote:
  Hi All,
 
  Anyone know how many rules should be performed when build TLS
  connection?
  I have some test case. The certificate time is not valid, validation
  failed. But the certificate passed if the validity dates of the
 child
  certificate are not contained within the validity
  dates of the parent certificate.
 
  As i know, both of above are the standard rules of digital
 certificate.

 I am not sure whether I understand you correctly. If the validity
 dates of
 the child certificate are not contained within the parent
 certificate, there
 should be no date at which both of them are valid at the same time!?
 Or do you mean that they somewhat overlap and the current date is
 within the overlapping region?


 This rule is independent of current time. e.g. If the validity dates
 of the parent certificate is 2008/04/18~2009/04/18 and the ones of
 child certificate is 2008/06/18~2009/06/18 or 2008/03/18~2009/03/18,
 the certificate chain should be invalid. The validity dates of child
 certificate should be between  the ones of parent(2008/04/18~2009/04/18).
Ok, so we are facing a violation of policies at the CA. At the date of
certificate verification we are however checking whether all components
of the certificate chain are valid at this day.
Even though the overlapping dates are a violation of the standard the
question is whether we actually should actually enforce this inside the
library. It might lead to a communication failure with site a lot of
poor souls set up without taking care of this fact...

Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: The rules of SSL-Certificate validation?

[Steffen DETTMER]

* Lutz Jaenicke wrote on Tue, Apr 22, 2008 at 09:59 +0200:
  This rule is independent of current time. e.g. If the validity dates
  of the parent certificate is 2008/04/18~2009/04/18 and the ones of
  child certificate is 2008/06/18~2009/06/18 or 2008/03/18~2009/03/18,
  the certificate chain should be invalid. The validity dates of child
  certificate should be between  the ones of parent(2008/04/18~2009/04/18).
 Ok, so we are facing a violation of policies at the CA. At the date of
 certificate verification we are however checking whether all components
 of the certificate chain are valid at this day.

 Even though the overlapping dates are a violation of the standard the
 question is whether we actually should actually enforce this inside the
 library.

Yes, maybe then a new CA certificate will be presented (with new
expiry dates), why not.

BTW, what is the idea/logic behind?
  I don't understand why this should be independent of current
  time. Maybe before the CA certificate expires, a new CA
  certificate will be presented without overlapping validity.
  Also, if the child certificate would be trusted if valid till
  2009/04/18 on 2009/04/17, I don't see why it should not be
  trusted at the same day (2009/04/17) if valid till 2009/04/19.
  I understand that in the second case the CA certificate is not
  trusted anymore, but this surely does depend on current time.

I've already read the idea that a CA should not certify for
longer than a certificate that is valid for the signing key - but
never understood why. Is this some standard requiring that or is
it just a matter of policy (and style maybe)? 

Where can I read/learn more?

Beside useless and expensive, wouldn't it be allowed (correct) if
the CA every day creates a new one-day-valid CA certificate?

Can it really be concluded from the expiry date of some
certificate whether the CA is authorised to certify or not? What
if the CA is authorised to certify for four years with a maximum
certificate duration of 30 days? (or whatever some policy
requires).

If it is just against the policy of some CAs and other reaonable
policies could be imagined, I think it should not be checked by
the library.

oki,

Steffen
 
About Ingenico Throughout the world businesses rely on Ingenico for secure and 
expedient electronic transaction acceptance. Ingenico products leverage proven 
technology, established standards and unparalleled ergonomics to provide 
optimal reliability, versatility and usability. This comprehensive range of 
products is complemented by a global array of services and partnerships, 
enabling businesses in a number of vertical sectors to accept transactions 
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose or take any action based on this 
message or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: The rules of SSL-Certificate validation?

[Kyle Hamilton]

On Tue, Apr 22, 2008 at 12:59 AM, Lutz Jaenicke [EMAIL PROTECTED] wrote:
  Ok, so we are facing a violation of policies at the CA. At the date of
  certificate verification we are however checking whether all components
  of the certificate chain are valid at this day.
  Even though the overlapping dates are a violation of the standard the
  question is whether we actually should actually enforce this inside the
  library. It might lead to a communication failure with site a lot of
  poor souls set up without taking care of this fact...

We've had this argument over on Mozilla's NSS group.  The 'root
certificate' is generally held, by Mozilla products, to be simply a
convenient container for holding the trust anchor, which is the public
key.  I've taken the argument that the holder of the private key
should be able to specify how long it wants that public key to be
trusted, after which it won't guarantee that it will hold the private
key any longer -- i.e., the 'expiration date' of the root certificate
should be a statement of policy about the root.  Unfortunately, my
argument was ignored.

There's what the standard says and what real-world implementations
of the standard do.  Unfortunately, the real-world implementations
don't follow the rules.

Is there any way to get a PEDANTIC_CERTIFICATE_RULES option?

-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

The rules of SSL-Certificate validation?

[Anri Lau]

Hi All,

Anyone know how many rules should be performed when build TLS connection?
I have some test case. The certificate time is not valid, validation failed.
But the certificate passed if the validity dates of the child certificate
are not contained within the validity
dates of the parent certificate.

As i know, both of above are the standard rules of digital certificate.

So, which rules will be performed in OpenSSL, when build the TLS connection.


-- 
Best regards to you and your family

Re: The rules of SSL-Certificate validation?

[Patrick Patterson]

Hi Anri:

Anri Lau wrote:
 Hi All,
 
 Anyone know how many rules should be performed when build TLS connection?
 I have some test case. The certificate time is not valid, validation failed.
 But the certificate passed if the validity dates of the child certificate
 are not contained within the validity
 dates of the parent certificate.
 
 As i know, both of above are the standard rules of digital certificate.
 
 So, which rules will be performed in OpenSSL, when build the TLS connection.
 
 
I believe that the above are what is performed, as well as, if you
provide the appropriate information, CRL validation (and, I believe,
OCSP can be added into the mix)...

However, OpenSSL does not *YET* perform full RFC3280 compliant Path
Validation and Discovery (checking for Name Constraints, Policy
compliance and mapping, AIA Chasing, etc.) - for that you need to either
do all of the implementation yourself, or use a tool like Pathfinder
(http://www.carillon.ca/products/pathfinder.php) that performs all of
this validation for you, and which ties into the OpenSSL certificate
verification callback.

Depending on the complexity of your trust environment (Pathfinder was
written to handle just about every case, including complex Bridge PKI
environments), you may not need that, and simply ensure that your code
reads the CRL Distribution point information in the certificate, and
either fetches the CRL, or uses a cached, but still valid copy of the
CRL, as then rely on the reasonably complete (for a simple trust
environment) implementation that is currently in part of the stock
certificate verification callback.

Have fun.

--
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: The rules of SSL-Certificate validation?

[Anri Lau]

Hi Patrick,

Thank you for your kindly reply.

I will do more research and test based on your advice. Actually, I want to
know which rules openssl has done, which should i implement in callback
function.

1.We make sure the chain we are going to build is present and that the first
entry is in place.
2.Verify the depth
3.Check a certificate chains extensions for consistency with the
supplied purpose
4.Check the last certificate trust in the chain
5 Check revocation status: we do this after copying parameters because
they may be needed for CRL signature verification.


On 18/04/2008, Patrick Patterson [EMAIL PROTECTED] wrote:

 Hi Anri:


 Anri Lau wrote:
  Hi All,
 
  Anyone know how many rules should be performed when build TLS
 connection?
  I have some test case. The certificate time is not valid, validation
 failed.
  But the certificate passed if the validity dates of the child
 certificate
  are not contained within the validity
  dates of the parent certificate.
 
  As i know, both of above are the standard rules of digital certificate.
 
  So, which rules will be performed in OpenSSL, when build the TLS
 connection.
 
 

 I believe that the above are what is performed, as well as, if you
 provide the appropriate information, CRL validation (and, I believe,
 OCSP can be added into the mix)...

 However, OpenSSL does not *YET* perform full RFC3280 compliant Path
 Validation and Discovery (checking for Name Constraints, Policy
 compliance and mapping, AIA Chasing, etc.) - for that you need to either
 do all of the implementation yourself, or use a tool like Pathfinder
 (http://www.carillon.ca/products/pathfinder.php) that performs all of
 this validation for you, and which ties into the OpenSSL certificate
 verification callback.

 Depending on the complexity of your trust environment (Pathfinder was
 written to handle just about every case, including complex Bridge PKI
 environments), you may not need that, and simply ensure that your code
 reads the CRL Distribution point information in the certificate, and
 either fetches the CRL, or uses a cached, but still valid copy of the
 CRL, as then rely on the reasonably complete (for a simple trust
 environment) implementation that is currently in part of the stock
 certificate verification callback.

 Have fun.

 --

 Patrick Patterson
 Chief PKI Architect
 Carillon Information Security Inc.
 http://www.carillon.ca
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]




-- 
Best regards to you and your family

Re: The rules of SSL-Certificate validation?

[Anri Lau]

Hi Patrick,

Thank you for your kindly reply.

I will do more research and test based on your advice. Actually, I want to
know which rules openssl has done, which should i implement in callback
function.

The following are the rules implemented by openssl collected from source
code.

1.We make sure the chain we are going to build is present and that the
first entry is in place.
2.Verify the depth
3.Check a certificate chains extensions for consistency with the
supplied purpose
4.Check the last certificate trust in the chain
5 Check revocation status: we do this after copying parameters because
they may be needed for CRL signature verification.

Are these enough? Do you have more supplementary information?

On 18/04/2008, Patrick Patterson [EMAIL PROTECTED] wrote:

 Hi Anri:


 Anri Lau wrote:
  Hi All,
 
  Anyone know how many rules should be performed when build TLS
 connection?
  I have some test case. The certificate time is not valid, validation
 failed.
  But the certificate passed if the validity dates of the child
 certificate
  are not contained within the validity
  dates of the parent certificate.
 
  As i know, both of above are the standard rules of digital certificate.
 
  So, which rules will be performed in OpenSSL, when build the TLS
 connection.
 
 

 I believe that the above are what is performed, as well as, if you
 provide the appropriate information, CRL validation (and, I believe,
 OCSP can be added into the mix)...

 However, OpenSSL does not *YET* perform full RFC3280 compliant Path
 Validation and Discovery (checking for Name Constraints, Policy
 compliance and mapping, AIA Chasing, etc.) - for that you need to either
 do all of the implementation yourself, or use a tool like Pathfinder
 (http://www.carillon.ca/products/pathfinder.php) that performs all of
 this validation for you, and which ties into the OpenSSL certificate
 verification callback.

 Depending on the complexity of your trust environment (Pathfinder was
 written to handle just about every case, including complex Bridge PKI
 environments), you may not need that, and simply ensure that your code
 reads the CRL Distribution point information in the certificate, and
 either fetches the CRL, or uses a cached, but still valid copy of the
 CRL, as then rely on the reasonably complete (for a simple trust
 environment) implementation that is currently in part of the stock
 certificate verification callback.

 Have fun.

 --

 Patrick Patterson
 Chief PKI Architect
 Carillon Information Security Inc.
 http://www.carillon.ca
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]




-- 
Best regards to you and your family

Re: The rules of SSL-Certificate validation?

[Lutz Jaenicke]

Anri Lau wrote:
 Hi All,

 Anyone know how many rules should be performed when build TLS
 connection? 
 I have some test case. The certificate time is not valid, validation
 failed. But the certificate passed if the validity dates of the child
 certificate are not contained within the validity
 dates of the parent certificate.

 As i know, both of above are the standard rules of digital certificate.
I am not sure whether I understand you correctly. If the validity dates of
the child certificate are not contained within the parent certificate, there
should be no date at which both of them are valid at the same time!?
Or do you mean that they somewhat overlap and the current date is
within the overlapping region?

Best regards,
Lutz
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: The rules of SSL-Certificate validation?

[Anri Lau]

Hi Luzt,

On 18/04/2008, Lutz Jaenicke [EMAIL PROTECTED] wrote:

 Anri Lau wrote:
  Hi All,
 
  Anyone know how many rules should be performed when build TLS
  connection?
  I have some test case. The certificate time is not valid, validation
  failed. But the certificate passed if the validity dates of the child
  certificate are not contained within the validity
  dates of the parent certificate.
 
  As i know, both of above are the standard rules of digital certificate.

 I am not sure whether I understand you correctly. If the validity dates of
 the child certificate are not contained within the parent certificate,
 there
 should be no date at which both of them are valid at the same time!?
 Or do you mean that they somewhat overlap and the current date is
 within the overlapping region?


This rule is independent of current time. e.g. If the validity dates of the
parent certificate is 2008/04/18~2009/04/18 and the ones of child
certificate is 2008/06/18~2009/06/18 or 2008/03/18~2009/03/18, the
certificate chain should be invalid. The validity dates of child certificate
should be between  the ones of parent(2008/04/18~2009/04/18).



Best regards,

 Lutz

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]




-- 
Best regards to you and your family

Re: Do I need to do anything special to get certificate validation to use a CDP?

[Bruce Keats]

Thank you.  Is there a function within the API that can do the CRL
extraction from the CDP(s)?

Bruce

On Dec 22, 2007 4:32 AM, Cong Zhang [EMAIL PROTECTED] wrote:

 Hi,

 AFAIK, OpenSSL has no code to retrieve the CRL from CRL distribution
 points. The CRL retrieve and update should be done by yourself.
 However, by putting a PEM encoded CRL to CApath will make OpenSSL load
 this CRL correctly.

 To use CRL, you may retrieve and check CRL at verify_callback, or use
 an out-of-band manner to retrieve CRL at intervals and put it to
 CApath.

 Thanks,
 Zhang Cong

 On Dec 21, 2007 2:24 AM, Bruce Keats [EMAIL PROTECTED] wrote:
  Hi,
 
  I have an TLS/SSL client I wrote using openssl and I was wondering if I
 have
  to do anything special to verify if a certificate was revoked in one of
 the
  CRLs taken from one of the CDPs?  Is there special code or calls I need
 to
  make in the verify_callback() that is installed by SSL_CTX_set_verify()?
  Is
  this handled automatically by openssl?  If so then how long is the CRL
  cached?
 
  This may seem like a simple question, but I have been unable to find the
  code that actually does this.  I found the CRL_DIST_POINTS type in
  crypto/x509v3/x509.h, but I don't seem to be able to find any code that
  looks like it is talking to the CDP to get the CRLs using this
  CRL_DIST_POINTS.
 
  I am using 0.9.8g.
 
  Thanks,
  Bruce
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   [EMAIL PROTECTED]

Re: Do I need to do anything special to get certificate validation to use a CDP?

[Cong Zhang]

I remember that most CDPs are HTTP URL, LDAP URL, a UNC string, etc. I
did not checked the standard for all supported formats, but HTTP URL
is the most common. So you may use any tools supports HTTP to retrieve
them, such as wget or curl.

For example, in my browser there is an CA certificate issued by Comodo
CA Limited, with CN AAA Certificate Services, the CDP is the
following 2 URLs:
  URI:http://crl.comodoca.com/AAACertificateServices.crl
  URI:http://crl.comodo.net/AAACertificateServices.crl

You can use curl or wget to get them. However, I don't think OpenSSL
has API to do this job.

Zhang Cong

On Dec 24, 2007 9:55 PM, Bruce Keats [EMAIL PROTECTED] wrote:
 Thank you.  Is there a function within the API that can do the CRL
 extraction from the CDP(s)?

 Bruce



 On Dec 22, 2007 4:32 AM, Cong Zhang [EMAIL PROTECTED] wrote:

 
 
 
  Hi,
 
  AFAIK, OpenSSL has no code to retrieve the CRL from CRL distribution
  points. The CRL retrieve and update should be done by yourself.
  However, by putting a PEM encoded CRL to CApath will make OpenSSL load
  this CRL correctly.
 
  To use CRL, you may retrieve and check CRL at verify_callback, or use
  an out-of-band manner to retrieve CRL at intervals and put it to
  CApath.
 
  Thanks,
  Zhang Cong
 
 
 
 
  On Dec 21, 2007 2:24 AM, Bruce Keats [EMAIL PROTECTED] wrote:
   Hi,
  
   I have an TLS/SSL client I wrote using openssl and I was wondering if I
 have
   to do anything special to verify if a certificate was revoked in one of
 the
   CRLs taken from one of the CDPs?  Is there special code or calls I need
 to
   make in the verify_callback() that is installed by SSL_CTX_set_verify()?
 Is
   this handled automatically by openssl?  If so then how long is the CRL
   cached?
  
   This may seem like a simple question, but I have been unable to find the
   code that actually does this.  I found the CRL_DIST_POINTS type in
   crypto/x509v3/x509.h, but I don't seem to be able to find any code that
   looks like it is talking to the CDP to get the CRLs using this
   CRL_DIST_POINTS.
  
   I am using 0.9.8g.
  
   Thanks,
   Bruce
  __
  OpenSSL Project http://www.openssl.org
  User Support Mailing Listopenssl-users@openssl.org
  Automated List Manager   [EMAIL PROTECTED]
 


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Do I need to do anything special to get certificate validation to use a CDP?

[Bruce Keats]

Hi,

I have an TLS/SSL client I wrote using openssl and I was wondering if I have
to do anything special to verify if a certificate was revoked in one of the
CRLs taken from one of the CDPs?  Is there special code or calls I need to
make in the verify_callback() that is installed by SSL_CTX_set_verify()?  Is
this handled automatically by openssl?  If so then how long is the CRL
cached?

This may seem like a simple question, but I have been unable to find the
code that actually does this.  I found the CRL_DIST_POINTS type in
crypto/x509v3/x509.h, but I don't seem to be able to find any code that
looks like it is talking to the CDP to get the CRLs using this
CRL_DIST_POINTS.

I am using 0.9.8g.

Thanks,
Bruce

What happens if certificate validation failes - what s_client error codes exist?

[Peter Asemann]

I was going to write a perl script that updates my ip at dyndns.org
using a secure connection, making use of openssl s_client to keep it
simple (and to avoid newbie mistakes).
I use the -CAfile to point to the Thawte root certificate I got from
thawte.com as dyndns.org uses a Thawte-signed certificate.
What I do exactly is:
openssl s_client -CAfile /path/to/thawte/certificate -connect
www.dyndns.org:443
Now this faciliates quite a lot of output and lots of verify return:1
lines, and in the end a block with SSL session id and Verify return
code: 0 (ok).
As I could not find any comment about the s_client's error codes I'm not
quite sure if and how I could detect the SSL connection has been
established and the server's certificate was accepted.
Does no verify return codes except 1 and 0 mean everything is okay?
Thanks for reading and best regards,
Peter Asemann
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Jason Haar]

Richard A. Faulk Jr. wrote:
I just tried setting the crl file to DER encoding and specified that files 
with .crl extensions are application/x-x509-crl.  I am still receiving the 
certificate validation failure error on the Cisco concentrator.  Is there 
anything else that I need to do?  Am I doing something wrong?

 

You are referring to the VPN-3000 series aren't you? And running a 1 
year old release?

It works for us...
Jason
PS: use curl -i http://site/file.crl | more to view what the cert 
really looks like. It should be Content-type:
application/x-x509-crl and the contents should be binary.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Richard A. Faulk Jr.]

Jason,

I'm glad to hear that someone else has a similar scenario working.  I am a 
little bit new to this.  I am publishing the CRL with Apache.  I placed a 
copy of the file in the default DocumentRoot in a folder named crl. I can 
access the file from Internet Explorer.

How do I ensure that the URL is application/x-x509-crl ?  Is this something 
that can be generated into the DER encoded crl using openssl?

Also, rather than just making a copy of the crl file and placing it in a 
different location for publishing, do I need to maintain the openssl CA 
directory structure for this to work?

Thank you in advance for your assistance.


Richard A. Faulk Jr., MCSE, ASE, CCA, Linux+
Plummer Slade, Inc.
Tel: (412)261-5600 x226
[EMAIL PROTECTED]
http://www.plummerslade.com

- Original Message - 
From: Jason Haar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 22, 2004 20:30
Subject: Re: Certificate validation failure, Successful



We do this here.

Ensure your URLs are application/x-x509-crl, and the CRL is DER
encoded and you'll be fine.

Cisco did a real good job with their PKI support in the VPN-3000 series
- I wish I could say the same for IOS (our CA has a serial number of
0, and IOS refuses to trust a CA with a serial 1.  Strange - I always
thought 0 was an integer as required by the SSL RFCs... :-()

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Dr. Stephen Henson]

On Tue, Nov 23, 2004, Jason Haar wrote:

 
 Cisco did a real good job with their PKI support in the VPN-3000 series 
 - I wish I could say the same for IOS (our CA has a serial number of 
 0, and IOS refuses to trust a CA with a serial 1.  Strange - I always 
 thought 0 was an integer as required by the SSL RFCs... :-()
 

The RFCs were a bit ambiguous on that score. Various people have said
since that 0 shouldn't be used as a serial number so OpenSSL doesn't do this
by default in the very latest versions (it uses a random 64 bit serial number
instead).

Various public CAs have zero as a serial number: some of the Thawte ones for
example.

However that's just the rules for generating serial numbers. As is usual the
criteria for acceptance are more general. For example in RFC3280 4.1.2.2:

Non-conforming CAs may issue certificates with serial numbers
that are negative, or zero.  Certificate users SHOULD be prepared to
gracefully handle such certificates.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Richard A. Faulk Jr.]

I just tried setting the crl file to DER encoding and specified that files 
with .crl extensions are application/x-x509-crl.  I am still receiving the 
certificate validation failure error on the Cisco concentrator.  Is there 
anything else that I need to do?  Am I doing something wrong?

Thanks,


Richard A. Faulk Jr., MCSE, ASE, CCA, Linux+
Plummer Slade, Inc.
Tel: (412)261-5600 x226
[EMAIL PROTECTED]
http://www.plummerslade.com

- Original Message - 
From: Richard A. Faulk Jr. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 23, 2004 08:07
Subject: Re: Certificate validation failure, Successful


Jason,

I'm glad to hear that someone else has a similar scenario working.  I am a
little bit new to this.  I am publishing the CRL with Apache.  I placed a
copy of the file in the default DocumentRoot in a folder named crl. I can
access the file from Internet Explorer.

How do I ensure that the URL is application/x-x509-crl ?  Is this something
that can be generated into the DER encoded crl using openssl?

Also, rather than just making a copy of the crl file and placing it in a
different location for publishing, do I need to maintain the openssl CA
directory structure for this to work?

Thank you in advance for your assistance.


Richard A. Faulk Jr., MCSE, ASE, CCA, Linux+
Plummer Slade, Inc.
Tel: (412)261-5600 x226
[EMAIL PROTECTED]
http://www.plummerslade.com

- Original Message - 
From: Jason Haar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 22, 2004 20:30
Subject: Re: Certificate validation failure, Successful



We do this here.

Ensure your URLs are application/x-x509-crl, and the CRL is DER
encoded and you'll be fine.

Cisco did a real good job with their PKI support in the VPN-3000 series
- I wish I could say the same for IOS (our CA has a serial number of
0, and IOS refuses to trust a CA with a serial 1.  Strange - I always
thought 0 was an integer as required by the SSL RFCs... :-()

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Richard A. Faulk Jr.]

I just tried setting the crl file to DER encoding and specified that files 
with .crl extensions are application/x-x509-crl.  I am still receiving the 
certificate validation failure error on the Cisco concentrator.  Is there 
anything else that I need to do?  Am I doing something wrong?

Thanks,


Richard A. Faulk Jr., MCSE, ASE, CCA, Linux+
Plummer Slade, Inc.
Tel: (412)261-5600 x226
[EMAIL PROTECTED]
http://www.plummerslade.com

- Original Message - 
From: Richard A. Faulk Jr. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, November 23, 2004 08:07
Subject: Re: Certificate validation failure, Successful


Jason,

I'm glad to hear that someone else has a similar scenario working.  I am a
little bit new to this.  I am publishing the CRL with Apache.  I placed a
copy of the file in the default DocumentRoot in a folder named crl. I can
access the file from Internet Explorer.

How do I ensure that the URL is application/x-x509-crl ?  Is this something
that can be generated into the DER encoded crl using openssl?

Also, rather than just making a copy of the crl file and placing it in a
different location for publishing, do I need to maintain the openssl CA
directory structure for this to work?

Thank you in advance for your assistance.


Richard A. Faulk Jr., MCSE, ASE, CCA, Linux+
Plummer Slade, Inc.
Tel: (412)261-5600 x226
[EMAIL PROTECTED]
http://www.plummerslade.com

- Original Message - 
From: Jason Haar [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, November 22, 2004 20:30
Subject: Re: Certificate validation failure, Successful



We do this here.

Ensure your URLs are application/x-x509-crl, and the CRL is DER
encoded and you'll be fine.

Cisco did a real good job with their PKI support in the VPN-3000 series
- I wish I could say the same for IOS (our CA has a serial number of
0, and IOS refuses to trust a CA with a serial 1.  Strange - I always
thought 0 was an integer as required by the SSL RFCs... :-()

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Certificate validation failure, Successful

[Richard A. Faulk Jr.]

I have configured a Cisco VPN 3005 concentrator to use digital certificate 
authentication successfully with openssl.  However, whenever I configure the 
concentrator to read the CRL file via http, I receive a Certificate 
validation failure and the VPN client fails to connect.  I am using the same 
CA that is configured on the concentrator to generate the CRL, and the 
certificate on the client has not been revoked.

I am running a Red Hat 8.0 server with OpenSSL 0.9.6b.

I generated the CRL using the following command :

openssl ca -gencrl -keyfile private/cakey.pem -cert cacert.pem -out 
crlfile.crl

I have verified that the concentrator can access this file. (Removing read 
permissions from the file results in an access error on the concentrator.)

The error log entries are as follows:

351 11/22/2004 15:21:23.850 SEV=5 CERT/116 RPT=18
Requesting CRL using HTTP. The HTTP URL is: 
http://192.168.1.98/crl/crlfile.crl

352 11/22/2004 15:21:23.860 SEV=4 IKE/80 RPT=18
66.123.111.19
Group [VPNClient]
Certificate validation failure, Successful
(CN=ClientTest, SN=06)

354 11/22/2004 15:21:23.870 SEV=5 IKE/194 RPT=19 66.123.111.19
Group [VPNClient]
Sending IKE Delete With Reason message: No Reason Provided.

Is there something different that I have to do to create a valid CRL that 
meets industry standards? The VPN client can connect successfully if the 
concentrator is not configured to perform CRL checking.  Any help would be 
greatly appreciated.

Rich Faulk

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Dr. Stephen Henson]

On Mon, Nov 22, 2004, Richard A. Faulk Jr. wrote:

 I have configured a Cisco VPN 3005 concentrator to use digital certificate 
 authentication successfully with openssl.  However, whenever I configure the 
 concentrator to read the CRL file via http, I receive a Certificate 
 validation failure and the VPN client fails to connect.  I am using the same 
 CA that is configured on the concentrator to generate the CRL, and the 
 certificate on the client has not been revoked.
 
 I am running a Red Hat 8.0 server with OpenSSL 0.9.6b.
 
 I generated the CRL using the following command :
 
 openssl ca -gencrl -keyfile private/cakey.pem -cert cacert.pem -out 
 crlfile.crl
 
 I have verified that the concentrator can access this file. (Removing read 
 permissions from the file results in an access error on the concentrator.)
 
 The error log entries are as follows:
 
 351 11/22/2004 15:21:23.850 SEV=5 CERT/116 RPT=18
 Requesting CRL using HTTP. The HTTP URL is: 
 http://192.168.1.98/crl/crlfile.crl
 
 352 11/22/2004 15:21:23.860 SEV=4 IKE/80 RPT=18
 66.123.111.19
 Group [VPNClient]
 Certificate validation failure, Successful
 (CN=ClientTest, SN=06)
 
 354 11/22/2004 15:21:23.870 SEV=5 IKE/194 RPT=19 66.123.111.19
 Group [VPNClient]
 Sending IKE Delete With Reason message: No Reason Provided.
 
 Is there something different that I have to do to create a valid CRL that 
 meets industry standards? The VPN client can connect successfully if the 
 concentrator is not configured to perform CRL checking.  Any help would be 
 greatly appreciated.
 

You might want to try converting the CRL to DER and seeing if it needs a
specific MIME type, you might try application/pkix-crl for example. 

You could also try putting invalid data at the relevant URL to see if you get
a different error: that might confirm it was accepting the CRL but wanted some
additional details in its content.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Certificate validation failure, Successful

[Jason Haar]

We do this here.
Ensure your URLs are application/x-x509-crl, and the CRL is DER 
encoded and you'll be fine.

Cisco did a real good job with their PKI support in the VPN-3000 series 
- I wish I could say the same for IOS (our CA has a serial number of 
0, and IOS refuses to trust a CA with a serial 1.  Strange - I always 
thought 0 was an integer as required by the SSL RFCs... :-()

--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Certificate validation

[Keary Suska]

I am wondering if openssl can be used in an application such that a
certificate is checked locally on application startup as a license
verification measure.

My idea is to install a certificate, then have the application validate it
during launch to verify that execution is permitted. Is this possible to do
without allowing a user on the machine to modify the certificate to
circumvent this measure?

Keary Suska
Esoteritech, Inc.
Leveraging Open Source for a better Internet

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Client -server certificate validation

[Sudeep Sudhakaran]

Hi,

I have seen a lot of posting on client certificate validation. But no clean 
answer to client authentication. I see a reply and finally the poster 
replies saying it doesnt work.  It seems a lot of people have problems with 
this and never got a perfect answer.


I like to implement mutual certificate authentication. I used the sample 
code in all the postings.
Whenever I do a get_peer_certificate function on the serverside, it returns 
NULL. Being the prime contact person on this list, could you please help me 
setting up a sample client program which presents certificate to server so 
that get_peer_Certificate wont return NULL and I can do verify on the 
certificate.



Sudeep






From: Lutz Jaenicke [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Client -server certificate validation
Date: Thu, 7 Dec 2000 23:23:17 +0100

On Thu, Dec 07, 2000 at 04:34:43PM -0500, Sudeep Sudhakaran wrote:
  I am trying to run s_server.c and s_client.c.  I am trying to include 
two
  way certificate verification.
 
  Whenever I do a peer=SSL_get_peer_certificate(con); on the server side 
it
  always returns null. I am specifiying a client certificate on the 
s_client.c
 
  I am not that used to these certificate stuff. So I picked up the 
client.pem
  /server.pem which comes with apps samples for client/server.
 
  I tried searching for
  SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) and I cant find what 
is
  CAfile and CApath. Is there something I should specifiy here..

Please check out the latest state of the documentation available at
www.openssl.org. There are several links at the bottom of ssl(3).
Please check especially SSL_CTX_set_verify(3) and
SSL_CTX_load_verify_locations(3).

If this is not enough, check out the mailing list archive and search for
SSL_VERIFY_PEER  client certificate. You will see, that this topic has
been discussed several times in the past.

Best regards,
   Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

_
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Client -server certificate validation

[Lutz Jaenicke]

On Fri, Dec 08, 2000 at 11:14:07AM -0500, Sudeep Sudhakaran wrote:
 Hi,
 
 I have seen a lot of posting on client certificate validation. But no clean 
 answer to client authentication. I see a reply and finally the poster 
 replies saying it doesnt work.  It seems a lot of people have problems with 
 this and never got a perfect answer.
 
 
 I like to implement mutual certificate authentication. I used the sample 
 code in all the postings.
 Whenever I do a get_peer_certificate function on the serverside, it returns 
 NULL. Being the prime contact person on this list, could you please help me 
 setting up a sample client program which presents certificate to server so 
 that get_peer_Certificate wont return NULL and I can do verify on the 
 certificate.

First step is to understand the TLS protocol. The client will present
a certificate if and only if explicitly asked by the server.
Hence it is mandatory to use the SSL_CTX_set_verify() command in the
server software:
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, callback_function);
(More details to be found in the manual page for SSL_CTX_set_verify().)

If this flag is being set, an OpenSSL client doing SSL_connect() will send
its certificate (provided certificate and private key have been installed
succesfully) to the server.
(More details: the server will send a list of CAs of which it will accept
client certificates; OpenSSL clients tend to ignore this list and send
the certificate they have, matching the CA or not. To use this CA list
feature, please check out the manual pages for SSL_CTX_load_verify_locations()
and SSL_CTX_set_client_CA_list().)

If you don't have these manual pages available, the latest state can always
be accessed in the documentation section at www.openssl.org.

The s_server and s_client applications as part of the OpenSSL package
successfully use certificates.
I am successfully using certificates with my Postfix/TLS patchkit (SMTP with
TLS enhancement for the postfix email-software), which is available from
my homepage. I can 100% assure you that it works!

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]