>From: [email protected] On Behalf Of Paul Pazandak
>Sent: Tuesday, 21 May, 2013 21:58
>To: [email protected]
I don't think this is a -dev question, but not worth changing.
>We want to be able to handle long-lived connections/sessions,
>and we are therefore wondering about situations where a client
>or server certificate may expire either 1)after we have established
>a context, or 2)after a session has started. Perhaps the first
>question is: how often is a certificate validated?
>[if there are docs that describe the certificate lifecycle
>(I couldn't find them), pls point us to them!]
*certificate* lifecycle (approval, issuance, expiration, revocation,
distribution, etc.) is external to SSL/TLS.
*session* lifecycle is kind of implicit in the TLS RFCs
but I don't recall seeing any separate doc on it.
You need to to distinguish here between "context" (internal to
openssl), "session" and "connection" which are not the same.
>From an initial digging into the code, it appears that the
>certificate is only validated before a session is set up.
>So, if a cert expires after this, it will never be detected
>as long as the session is running. Is this true?
When a *session* is set up, yes. You normally create a (new)
SSL/TLS connection by doing a full handshake which among other
things validates the cert and creates a session; the session
is basically the master-secret and authentication info.
You can then create additional connections using the same
session, commonly called "resumption", if both endpoints
(server and client) support it; openssl server does within
a process by itself, and cross-process with some assistance;
openssl client does only with some application help.
Conversely and applicable to your question, you can create a
new session on an existing connection, called "renegotiation",
again if both endpoints support it. Most do, but during the
Apache-prefix vulnerability and exploit in late 2009, some
implementations (including IIRC 1 or 2 versions of openssl)
and many systems and people turned off renegotiation entirely
as a sledgehammer fix. There is now a better fix (RFC 5746)
but unless both/all the endpoints are under your control
you may encounter some that don't support or deploy it.
>Do we have to programmatically manage expiring certs (dealing
>with expiring certs & adding new certs) within our app, or is
>it possible to point to a cert store that we can then update
>external to the app (e.g. with a new cert via the openSSL
>command line tool) and then have the openSSL lib manage it?
Those are really two or three different questions.
To check if the peer cert expires (or is revoked) during a
session you can either reverify yourself (for expiration
you can just get the notAfter time and check it, but for
revocation you need to get a fresh CRL or OCSP or similar),
or you can direct openssl to renegotiate (explicitly, or
if you use ssl-BIO by setting time and/or data limits).
To change your "own" cert and key (the one the server uses
to authenticate to the client, or the client uses if you
use client authentication) your code must re-call
_usePrivateKey and _useCertificate or _use...Chain.
This will be needed if/before your cert has expired or
been revoked and you want to start a new session.
If a peer cert expires (or is revoked) but the peer gets
a new cert under a CA root that remains valid, openssl will
aceept that under the existing truststore. Most public CAs
have root periods of decades precisely to allow this.
If a peer replaces an expired selfsigned cert, or gets
a new cert under a CA root that is not already trusted:
- if you used _load_verify_loc...(,file,), equivalent to
-CAfile on some openssl commandline (and possibly other apps),
your code must re-call to re-read the file.
- if you used _load_verify_loc...(,,dir), equivalent to
-CApath, you can just put the new cert in there, *with*
the correct hashlink or (on Windows) hashname, and it
will be found dynamically when verification is next done.
- if you used both file and dir, it depends on where you
put the new cert(s)
- if you used _default_verify_paths and the default file
and/or dir exist, ditto
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
