Lars Weber wrote:
>
> Hello everybody !
>
> I have some (late) suggestions for the next OpenSSL-Release:
>
> 1) Fingerprint for requests
>
> It would be nice to see an option "fingerprint" for the "req" application,
> like in the "x509" application.
>
> For example:
>
> openssl req -fingerprint -in req.pem
>
> This should calculate a unique fingerprint for the request and would
> make it possible to identify a request via this hash. I think this
> would be very helpful for CAs (well, at least it'd be for us :-).
> Eg., we would ask the requester of a certificate to write down the
> fingerprint of the CSR on some kind of agreement form prior to the
> certification process. We would then compare the fingerprint with
> what openssl shows us.
Calculating a fingerprint is possible using the md5 algorithm, try using
that ... anyway I use, instead, the serial number of the issued certificate
to identify corresponding request.
req->issue cert->get cert serial->archive req as serial=>$req
So I have all corresponding requests to certificates stored in an NDBM
file (using perl is so simple... ). When I get a renewal request, simple
issue a new cert from the original req.
> 2) Serial-number and entry in index.txt for self-signed-certs
>
> I have realized that a root-cert that was generates via req -x509...
> always gets the serial-number "00". I think this could lead to some
> trouble if you want to renew the root-cert (for whatever reason) with
> the same subject name. So it would be good idea to use the value in
> the file "serial".
> And for consistency it should be possible to have the choice to include
> the corresponding values for the root-cert in "index.txt".
As you don't issue a root cert using the -ca command I think this could
be confusing as we generally do not need to load config files and do not
have the need to configure dirs and so on (serial file, index.txt, etc.)
> 3) Strange behavior if "serial" is set to "00"
>
> If someone puts the value "00" in serial instead of "01", that will
> cause some funny things after issuing the first cert. The
> "serial"-file contains "5C5C5C5D" and the serial-number of the new
> certs is set to "0".
>
Got to check for it ...
> 4) Missing directory "newcerts"
>
> "make install" doesn't create the directory "newcerts", suggested by
> the default-configfile "openssl.cnf".
>
> 5) New option "-chkdb" for the "ca"-application
>
> Invoking "ca" with this option should check "index.txt" for expired
> certs and mark them with an 'E' in the first column. The idea is that
> it is possible to run "openssl ca -chkdb" periodically via a cron-job
> and keep "index.txt" up-to-date. This is important if you use
> "index.txt" for online-checking (server-)certs via the extension
> nsRevocationUrl.
I think it would be more "friendly" calling it
$ openssl ca -updatedb
a bit longer, but more readable... (I think... )
> I have patched this functionality in the "revoke.c"-file originally
> posted long ago by "[EMAIL PROTECTED]" (sorry, can't find his
> real name) and Sergio Tabanelli. I have repost this program at the end
> of march (jfi).
> If it would be useful i can repost it with the "chkdb"-patches.
Sure.
As I modified the ca.c file to include a "updated" version of the revoke
utility that has been included in the release, if you send me the patched
revoke.c with comments I'll be glad to include it in the ca.c (or just
send it into the dev list, better).
Hope to hear you soon,
Massimiliano Pala ([EMAIL PROTECTED])
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
