Thank You sooo much Kyle and Tomas,
Another question. I have a Linux machine that is running openssl 0.9.8g. It
looks like it uses CRL Version 1 ? Is this correct ? Is there a way to force
my openssl 0.9.8g to use CRL version 2 ???
In my network system, I have a Linux machine that has its own certificate, and
we have an external EJBCA server that we use to revoke certificates and
generate CRLs. The EJBCA supports CRLs per RFC 5280, which supposedly means
that it supports X.509 version 2 CRLs ?
When we revoke the Linux machine's certificate on the EJBCA server,
successfully download the CRL from the EJBCA server onto my Linux machine,
{even though the serial number of the Linux machine's certificate appears in
the downloaded CRL file}, my Linux machine doesn't seem to be affected by the
CRL at all :-( I made sure the openssl.cnf file points to the downloaded CRL
file, and no effect whatsoever !
Now, when I generate self-signed certificates on the Linux machine, and I also
generate corresponding CRL using openssl commands, this method does seem to
work, in the sense that the revoked certificate is no longer usable.
I compared the CRLs in the self-sgned case compared to the CRLs generated by
the EJBCA.
The self-signed CRL was version 1, and the EJBCA generated CRL was version 2.
Is there any obvious reason why openssl0.9.8g, which seems to run with CRL
Version 1, doesn't seem to work with a downloaded CRL that happens to be
version 2 CRL ?
Again, is there a way to force openssl 0.9.8g to work with version 2 CRLs ?
Please help. Thanks a bunch in advance...
-----Original Message-----
From: Tomas Gustavsson [mailto:[email protected]]
Sent: Monday, September 27, 2010 3:27 AM
To: [email protected]
Cc: Hasan Rezaul-CHR010
Subject: Re: Signed Certificates and Revoking the Certs with CRLs
Why no try the open source PKI book as a starter...
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm
Cheers,
Tomas
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Kyle Hamilton
Sent: Saturday, September 25, 2010 12:11 AM
To: [email protected]
Subject: Re: Signed Certificates and Revoking the Certs with CRLs
Well, here's the overview:
The CRL is a mechanism used by the attesting entity (the CA) to change the
validity status of a previously-issued certificate (digitally-provable
statement of authority by a particular named entity, i.e. the CA).
The certificate, which is best viewed as a record of the act of certifying, is
a mathematically-hard transformation of the output of a
(universally) lossy compression algorithm over a particular form and style of
data structure, and the data structure itself. The function of the data
structure is to assert the ownership of a secret number, as witnessed by the
ability to perform transformations with the counterpart public number which is
included in the data structure.
The purpose is to "strongly bind" the legal identity of the entity applying for
the certificate and the public half of an asymmetric keypair (the private key
of which is kept private, but evidence of its possession and ability to perform
the trapdoor operation is provided).
In order to create this, under X.509 there must be a trusted entity (the
certifier) whose credential is predistributed in some manner to all systems
that will need to rely on the identity claims it makes.
(X.509 is limited in two fatal (in my opinion) ways: First, everything is
reliant on the Distinguished Name... which isn't distinguished enough to
individually distinguish between all entities. Attributes are asserted as
relating to a particular DN, not a particular key.
Second, it relies on the concept of a single attestor, a single Source of
Authority -- when nothing in the Real World can rely upon any single identity
document to open an account, it's ludicrous to believe that banks or merchants
would accept the single word of a CA as to the identity provided. This causes
problems not only for the customer side, but also for the business side: if the
Authority that the business chooses to attest to its identity suddenly becomes
untrusted, then there is no help but a manual intervention that involves an
entire assurance of identity with another CA. No wonder most places choose to
go with domain-validated certificates. :( )
To generate keys and obtain certificates, every browser except IE appears to
support the old Netscape <keygen> HTML tag, which creates and puts into a form
submission what's called a SPKAC (Signed Public Key And Challenge) to the CA,
and the CA may either return a signed certificate immediately, turn down the
submission immediately, or hold the submission for manual intervention. The CA
is *solely* responsible for what shows up in the certificate. (Best current
practice seems to be, the CA drops everything that comes in the same structure
(SPKAC or CSR), and generates its own data structure with what it knows to be
true, and taking only your public key from the structure you submit after
verifying the signature.
These certificates have an expiration date, after which they are no longer
useful. (i.e., the CA's policy may say something like "the private key to any
certified public key cannot be in use for more than
24 months before being retired, because we won't accept the risk of it being
completely fatigued after that time".)
The CRL is one of two standardized mechanisms that the CA has to promulgate the
fact that a certificate's status is in abeyance. (The other is OCSP.) For
this to work, the end system must update its local copy of the CRL before it
can put any trust in it. It is important to note that OpenSSL does not provide
a means to *retrieve* CRLs (it doesn't have an HTTP client implementation), but
it does provide a mechanism to *use* CRLs that have already been retrieved.
(Usually, I use 'curl' or 'wget' to retrieve CRLs that I need to verify against
in scripts.)
Notably, the name "Certificate Revocation List" is a bit of a misnomer. It is
legitimate for a CA to put a certificate in abeyance, and then at some later
point decide that the certificate is actually valid and remove the certificate
in question from the CRL, thus indicating that the certificate is in fact good.
It's more of a "Certificate Status List". (This is at least partly because of
necessity -- the EU's Qualified Certificates are invalid until they are
"accepted by the subscriber". Thus, the Partial CRL profile has a specific bit
named: "removeFromCrl".
For a good place to learn more about how this is supposed to work, I would
recommend reading RFC 5280 (OpenSSL doesn't claim conformance to this version,
but it's the latest standard for the Internet PKI and explains what the various
standardized certifiate extensions mean, as well as describing the CRL
processing algorithm). For a very good place to learn about how to implement
this with OpenSSL, I would recommend Carillon's excellent "How to set up an
OpenSSL TEST CA for interoperability with CertiPath" document, available at
http://www.carillon.ca/library/openssl_testca_howto_1.3.pdf .
Also, it's a bit dated, but _Network Security with OpenSSL_ by John Viega, Matt
Messier, and Pravir Chandra (O'Reilly and Associates 2002) is still a good
reference.
There are some very deep flaws in how the revocation processing is handled
according to the RFC, most notably that the CRL location is in the end-entity
certificate, not in the CA certificate. If a valid X.509-formatted 2nd
preimage can be found that has the same hash as the valid certificate, and the
signature on the valid one then applied to the invalid one, the signature will
verify on the alternative content. This means that certificate processing
*must* be hardened against content-based attacks, because it only takes one
failure to compromise the system. (The MD5 hash algorithm was found to be weak
enough that such an attack was successfully mounted in 2009. This isn't idle
and paranoid speculation, this is a known and demonstrated
weakness.)
I hope this helps!
-Kyle H
On Fri, Sep 24, 2010 at 1:13 PM, Hasan Rezaul-CHR010 <[email protected]>
wrote:
> Hi All,
>
> Would anyone kindly point me to literature that CLEARLY explains
> exactly
> how:
>
> Certificates and CRLs may be used in conjunction such that certificate
> CSRs are generated, signed by an authority, then signed certs
> downloaded and being used on a system.
>
> At a later time, the certificate is revoked in the CRL, the CRL.pem
> file is downloaded on the system, and then the corresponding cert
> becomes unusable due to its mention in the CRL.
>
> Is there a good place for me to educate myself on this whole
> mechanism, and a place where it shows exactly how to implement all
> this with examples... Oh I am running on Linux, with openssl 0.9.8g.
>
> Thanks a bunch in advance.
> ______________________________________________________________________
> 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]
