Re: expired ssl certificate
The validity period of your root CA and server certificates depends on your Certificate Policy (CP). CP is a document that governs the operation of your PKI. It can be very simple and it can also be very complex. There are a lot of CPs which you can use as a reference. For server cert, with 1024 bit RSA with 2 to 3 years might be sufficient. Of course you have to renew your server cert when the cert is about to expired (1/2 of the validity period). You can renew the server cert, which mean you do not need to change the server private key or rekey. In rekey, the server got a new keypair and a new cert. The option you choose should be described in the CP. When the server cert is changed, you do not need to update (or touch) the client. The reason is, during the SSL handshake, the server always sends its certificate to the client (unless you are using SSL with pre-shared-key). Hence, server cert renew or reky is transparent to client. Erwin -- From: Dinh, Thao V CIV NSWCDD, K72 thao.d...@navy.mil Sent: Thursday, April 12, 2012 7:56 AM To: openssl-users@openssl.org Subject: RE: expired ssl certificate Thank You very, very much for all for help. I have a couple more questions: 1) what is max time you can have on expiration ?? 2) You wrote Create a long lived self-signed CA certificate (for example: 20 or 30 years).. Have this self-signed CA (trust anchor) created in step-1 issues the server certificate. For this server certificate, validity period does not matter. Should we make this server certificate as long as CA ?? Because making it short ( 5 years) , the handshanking will fail due to expired cert?? Thank again Nou, Erwin... Thao Dinh -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Erwin Himawan Sent: Wednesday, April 11, 2012 2:57 PM To: openssl-users@openssl.org Subject: Re: expired ssl certificate Reading Nou's proposal, I have the impression that the client needs to be modified to accept expired server's certificate. Is my understanding correct? If my understanding is corrrect, the client needs to be updated. If the client needs to be updated, In my opinion, it is simpler to update the client with a new server certificate. However, you should not use a selfsigned certificate for your serve certificate. Instead, I am proposing to create a chain of certificate (PKI). You could avoid this problem in the future by creating a simple PKI. FUrther you could expand this PKI to issue certificate for other application. This is what I am proposing: 1. Create a long lived self-signed CA certificate (for example: 20 or 30 years); This self-signed certificate is called trust anchor certificate. Make sure, basic constraint CA is set to true. Do not make the expiration less than 5 years, since you will have the same issue again in the next 5 year to roll-over your trust anchor certificate. Also, keep the private key of this CA as safe as possible. THis is your root of trust. If you compromise this root CA private key, your PKI becomes void. 2. Distribute this self-signed certificate to all clients and install this as the trusted certificate. 3. Have this self-signed CA (trust anchor) created in step-1 issues the server certificate. For this server certificate, validity period does not matter. Of course you do not want to make the validity period too short since you have to frequently update the server certificate when it is expired. Using this proposed method, you can update or change the server certificate as often as you like. The server certificate is typically included in the SSL's ServerHello message, so the client always got the server certificate during SSL handshake. I think (?) the server could also include the chain of certificate up to the trust anchor certificate. When the client receives the server certificate issued by the self-signed CA (the self-signed CA certificate could also be included in the ServerHello), the client can verify this certificate chain up to the self-signed CA certificate. If the chain can be verified, then the server certificate is successfully validated. Hence, the server can be cryptographically authenticated. Using Nou's proposal, your client would practically accept any self-signed certificate and prone to man-in-the-middle attack. The client can cryptographically verify the server certificate, but the client can not cryptographically authenticate the server since the client does not have the knowledge of the server's legitimate public key. Using my proposal, your client can cryptographically authenticate the server, by verifying the digital signature in the server's certificate using the (selfsigned) CA certificate. The selfsigned CA certificate is then verified against a list of trusted certificates. My proposal is actually similar with what you are doing currently
Re: expired ssl certificate
On Thu, Apr 12, 2012, Ashok C wrote: Hi, I had almost the same requirement and eventually achieved it by patching my openssl package's x509_verify code to do the check_cert_time() method optionally depending on some conditions. Ideally I feel openSSL should provide a validation flag like *X509_V_FLAG_IGNORE_LIFETIME **which would help in this case. I can see many existing flags listed here.** * http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html#VERIFICATION_FLAGS Is there any specific reason as to why OpenSSL does not want to support this feature? You can achieve the same by either changing the check time (using X509_VERIFY_PARAM_set_time) or using the verify callback to override the error X509_V_ERR_CERT_HAS_EXPIRED. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: expired ssl certificate
Thank You very, very much for all for help. I have a couple more questions:
1) what is max time you can have on expiration ??
2) You wrote
Create a long lived self-signed CA certificate (for example: 20 or 30
years)..
Have this self-signed CA (trust anchor) created in step-1 issues the server
certificate. For this server certificate, validity period does not matter.
Should we make this server certificate as long as CA ?? Because making it short
( 5 years) , the handshanking will fail due to expired cert??
Thank again Nou, Erwin...
Thao Dinh
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erwin Himawan
Sent: Wednesday, April 11, 2012 2:57 PM
To: openssl-users@openssl.org
Subject: Re: expired ssl certificate
Reading Nou's proposal, I have the impression that the client needs to be
modified to accept expired server's certificate. Is my understanding correct?
If my understanding is corrrect, the client needs to be updated.
If the client needs to be updated, In my opinion, it is simpler to update the
client with a new server certificate.
However, you should not use a selfsigned certificate for your serve
certificate. Instead, I am proposing to create a chain of certificate (PKI).
You could avoid this problem in the future by creating a simple PKI. FUrther
you could expand this PKI to issue certificate for other application.
This is what I am proposing:
1. Create a long lived self-signed CA certificate (for example: 20 or 30
years); This self-signed certificate is called trust anchor certificate. Make
sure, basic constraint CA is set to true.
Do not make the expiration less than 5 years, since you will have the same
issue again in the next 5 year to roll-over your trust anchor certificate.
Also, keep the private key of this CA as safe as possible. THis is your root
of trust. If you compromise this root CA private key, your PKI becomes void.
2. Distribute this self-signed certificate to all clients and install this as
the trusted certificate.
3. Have this self-signed CA (trust anchor) created in step-1 issues the server
certificate. For this server certificate, validity period does not matter. Of
course you do not want to make the validity period too short since you have to
frequently update the server certificate when it is expired.
Using this proposed method, you can update or change the server certificate as
often as you like.
The server certificate is typically included in the SSL's ServerHello message,
so the client always got the server certificate during SSL handshake. I think
(?) the server could also include the chain of certificate up to the trust
anchor certificate.
When the client receives the server certificate issued by the self-signed CA
(the self-signed CA certificate could also be included in the ServerHello), the
client can verify this certificate chain up to the self-signed CA certificate.
If the chain can be verified, then the server certificate is successfully
validated. Hence, the server can be cryptographically authenticated.
Using Nou's proposal, your client would practically accept any self-signed
certificate and prone to man-in-the-middle attack. The client can
cryptographically verify the server certificate, but the client can not
cryptographically authenticate the server since the client does not have the
knowledge of the server's legitimate public key. Using my proposal, your client
can cryptographically authenticate the server, by verifying the digital
signature in the server's certificate using the (selfsigned) CA certificate.
The selfsigned CA certificate is then verified against a list of trusted
certificates. My proposal is actually similar with what you are doing
currently. The difference between my proposal and yours is: in yours, you
verify the server certificate against a list of trusted certificates. In my
proposal, you verify the server certificate using the CA certificate which is
in a list of trusted certificates.
Erwin
On Wed, Apr 11, 2012 at 11:34 AM, Nou Dadoun ndad...@teradici.com wrote:
I'm no ssl guru either but I'll make some brief comments and let others
jump in if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will fail.
2. The verification callback is called after the regular
verification is performed, here's a simple example I posted with my own
question yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n
Re: expired ssl certificate
On Thu, Apr 12, 2012, Dinh, Thao V CIV NSWCDD, K72 wrote: Thank You very, very much for all for help. I have a couple more questions: 1) what is max time you can have on expiration ?? Technically the 31st December but you have to consider the security strength of the key used and how breakable it might be in future. Having a 30 year expiry date with a 1024 bit RSA key is not advisable for example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: expired ssl certificate
Hi Nou Please help me understand more about this subject ( I am new to Openssl) 1. What happen if the peer presents an expired certificate and we do not implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will the SSL_connect or SSL_accept fail ??? 2. What is the function of verification callback ? Just report error of expired certificate or actually let expired certificate be accepted ?? what is X509_.. function shoud I uses to let expired cert being accept ?? 3. what is the different between standard verify operation and the verify callback ??? Thank You Thao Dinh -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Nou Dadoun Sent: Tuesday, April 10, 2012 3:15 PM To: openssl-users@openssl.org Subject: RE: expired ssl certificate You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book (http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf ) page 132 or so has some sample code you can probably modify. Standard warnings apply .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam smime.p7s Description: S/MIME cryptographic signature
RE: expired ssl certificate
I'm no ssl guru either but I'll make some brief comments and let others jump in
if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will fail.
2. The verification callback is called after the regular verification is
performed, here's a simple example I posted with my own question yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
The ok parameter tells you whether the certificate passed so that if it's not
ok (didn't pass) you can examine the reason/error and the certificate itself to
see whether or not you want to over-rule that result. The return value
indicates whether you want to accept it or not - the above example only reports
the result (without changing it) and (if it fails) the reason for failure
without changing anything. If it's not ok and you look at the cert and it's
expired but you don't care, return 1 and it will be accepted. Look at the
examples in the pdf for some examples.
As I said earlier, standard warnings apply - you're overruling standard
security mechanisms for your own purposes which can be dangerous if you're not
careful.
3. I think I've answered that above N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dinh, Thao V CIV NSWCDD, K72
Sent: April 11, 2012 4:19 AM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
Hi Nou
Please help me understand more about this subject ( I am new to Openssl)
1. What happen if the peer presents an expired certificate and we do not
implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will
the SSL_connect or SSL_accept fail ???
2. What is the function of verification callback ? Just report error of
expired certificate or actually let expired certificate be accepted ?? what is
X509_.. function shoud I uses to let expired cert being accept ??
3. what is the different between standard verify operation and the verify
callback ???
Thank You
Thao Dinh
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Nou Dadoun
Sent: Tuesday, April 10, 2012 3:15 PM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
You can use a verification callback to look at the certificate after the
standard verify operation has been performed to decide whether or not to allow
the certificate anyway.
Look at the O'Reilly book
(http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf )
page 132 or so has some sample code you can probably modify.
Standard warnings apply .. N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Srihari, Gautam
Sent: April 10, 2012 3:04 AM
To: openssl-...@openssl.org; openssl-users@openssl.org
Subject: expired ssl certificate
Hi,
I have a server application and the client uses https to connect
to the server. For this I had created an openssl self signed certificate
cacert.pem which has been distributed to all the client applications.
Now unfortunately the certificate has expired. I can create a new
certificate.
But distributing to all the clients is going to be difficult.
Is there some way by using open ssl, I can make the server ignore expired
certificates
so I don't have to ask each client to update to a new certificate?
The crux of the problem is that I want to continue to allow clients to use the
server without
Having them to upgrade anything i.e change should be done only on the server
side.
Reg.,
Gautam
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: expired ssl certificate
] On Behalf Of Dinh, Thao V CIV NSWCDD, K72 Sent: April 11, 2012 4:19 AM To: openssl-users@openssl.org Subject: RE: expired ssl certificate Hi Nou Please help me understand more about this subject ( I am new to Openssl) 1. What happen if the peer presents an expired certificate and we do not implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will the SSL_connect or SSL_accept fail ??? 2. What is the function of verification callback ? Just report error of expired certificate or actually let expired certificate be accepted ?? what is X509_.. function shoud I uses to let expired cert being accept ?? 3. what is the different between standard verify operation and the verify callback ??? Thank You Thao Dinh -Original Message- From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Nou Dadoun Sent: Tuesday, April 10, 2012 3:15 PM To: openssl-users@openssl.org Subject: RE: expired ssl certificate You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book ( http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf) page 132 or so has some sample code you can probably modify. Standard warnings apply .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: expired ssl certificate
it or not - the above example only reports the result (without changing it) and (if it fails) the reason for failure without changing anything. If it's not ok and you look at the cert and it's expired but you don't care, return 1 and it will be accepted. Look at the examples in the pdf for some examples. As I said earlier, standard warnings apply - you're overruling standard security mechanisms for your own purposes which can be dangerous if you're not careful. 3. I think I've answered that above N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Dinh, Thao V CIV NSWCDD, K72 Sent: April 11, 2012 4:19 AM To: openssl-users@openssl.org Subject: RE: expired ssl certificate Hi Nou Please help me understand more about this subject ( I am new to Openssl) 1. What happen if the peer presents an expired certificate and we do not implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will the SSL_connect or SSL_accept fail ??? 2. What is the function of verification callback ? Just report error of expired certificate or actually let expired certificate be accepted ?? what is X509_.. function shoud I uses to let expired cert being accept ?? 3. what is the different between standard verify operation and the verify callback ??? Thank You Thao Dinh -Original Message- From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Nou Dadoun Sent: Tuesday, April 10, 2012 3:15 PM To: openssl-users@openssl.org Subject: RE: expired ssl certificate You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book ( http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf) page 132 or so has some sample code you can probably modify. Standard warnings apply .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: expired ssl certificate
You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book (http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf ) page 132 or so has some sample code you can probably modify. Standard warnings apply N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam
