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?
Regds,
Ashok
On Thu, Apr 12, 2012 at 12:26 AM, Erwin Himawan <ehima...@gmail.com> wrote:
> 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
>>
>
>
