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");
> }
> 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 List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
