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:tom...@primekey.se]
Sent: Monday, September 27, 2010 3:27 AM
To: openssl-users@openssl.org
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: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Kyle Hamilton
Sent: Saturday, September 25, 2010 12:11 AM
To: openssl-users@openssl.org
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<chr...@motorola.com>
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 openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
