Thread: File format for SSL CRL file

File format for SSL CRL file

From
Greg Smith
Date:
A documentation comment came in recently about ssl-tcp.html not
specifying what format is expected for the CRL file.  Seems like
something that could be described better now that I look at it, so I'm
passing that along with just wording edits from me; this is from user
"oneironautics":

The root.crl needs to be in PEM (and not DER) format.  If a certificate
file exists but is the wrong type, you will be told it cannot find the
file when it exists, with this sort of error in the log:

LOG:  SSL certificate revocation list file "root.crl" not found,
skipping: no SSL error reported
DETAIL:  Certificates will not be checked against revocation list.

This error can be reported even though you have a root.crl file in
$PGDATA along with the private key and server/root certificates.  A
quick check using openssl revealed that the unused CRL file in this
example was indeed in DER format.  Converting the certificate to the PEM
format rectified the error:

cd $PGDATA
openssl crl -inform der -in root.crl -outform pem -out root-new.crl
mv root-new.crl root.crl

Re: File format for SSL CRL file

From
Alvaro Herrera
Date:
Excerpts from Greg Smith's message of lun jul 02 20:30:07 -0400 2012:
> A documentation comment came in recently about ssl-tcp.html not
> specifying what format is expected for the CRL file.  Seems like
> something that could be described better now that I look at it, so I'm
> passing that along with just wording edits from me; this is from user
> "oneironautics":
>
> The root.crl needs to be in PEM (and not DER) format.  If a certificate
> file exists but is the wrong type, you will be told it cannot find the
> file when it exists, with this sort of error in the log:
>
> LOG:  SSL certificate revocation list file "root.crl" not found,
> skipping: no SSL error reported

HEAD is different in this area -- it dies with a FATAL instead of just
skipping it.

Also, the error message seems rather poor.  Maybe the code should call
X509_STORE_CTX_get_error() instead of SSLerrmessage (which calls
ERR_get_error; apparently not the right thing to do).

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Re: File format for SSL CRL file

From
Magnus Hagander
Date:
On Tuesday, July 3, 2012, Alvaro Herrera wrote:

Excerpts from Greg Smith's message of lun jul 02 20:30:07 -0400 2012:
> A documentation comment came in recently about ssl-tcp.html not
> specifying what format is expected for the CRL file.  Seems like
> something that could be described better now that I look at it, so I'm
> passing that along with just wording edits from me; this is from user
> "oneironautics":
>
> The root.crl needs to be in PEM (and not DER) format.  If a certificate
> file exists but is the wrong type, you will be told it cannot find the
> file when it exists, with this sort of error in the log:
>
> LOG:  SSL certificate revocation list file "root.crl" not found,
> skipping: no SSL error reported

HEAD is different in this area -- it dies with a FATAL instead of just
skipping it.

Yes, and if somebody forgot, that was an intentional change :)
 

Also, the error message seems rather poor.  Maybe the code should call
X509_STORE_CTX_get_error() instead of SSLerrmessage (which calls
ERR_get_error; apparently not the right thing to do).


I don't see how that would work - X509_STORE_CTX_get_error() takes an X509_STORE_CTX as parameter ,and we don't have one of those.

And unfortunately the function we use to load the store seems to be undocumented, so it's hard to know what we're supposed to use..

(I do agree we should try to figure out a better error message, of course..)

//Magnus
 


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: File format for SSL CRL file

From
Peter Eisentraut
Date:
On mån, 2012-07-02 at 20:30 -0400, Greg Smith wrote:
> The root.crl needs to be in PEM (and not DER) format.  If a
> certificate file exists but is the wrong type, you will be told it
> cannot find the file when it exists, with this sort of error in the
> log:

Could we instead fix it to accept both formats?  (Documenting it would
still be worthwhile, of course.)