Thread: [ADMIN] SSL certificate revocation file will not load

John Scalia <jayknowsunix@gmail.com> writes:
> I've got SSL working without the crl file, but when I set ssl_crl_file to
> use the one I have, it says FATAL on a restart and no SSL error reported.
> This is not very helpful.

Did you look into the postmaster log?  Experimenting with an intentionally
corrupted CRL file here, I get log messages along the lines of

2017-06-14 16:45:15.096 EDT [22759] LOG:  parameter "ssl_crl_file" changed to "root+client.crl"
2017-06-14 16:45:15.102 EDT [22759] LOG:  could not load SSL certificate revocation list file "root+client.crl": bad
base64decode 

The actually useful part of that comes out of OpenSSL, and we don't have
a lot of control about how specific it is ... but there should be
*something*.

            regards, tom lane

Well, it turned out that the CRL was in the wrong format. So, I managed to convert it with OpenSSL and it loaded
properly.I do have one more question... the Treasury Department, which produces these certificates for us, expires all
theCRL's in just 6 hours, so does that mean I'd have to do restart on the database each time I got a new one or would a
reloadwork? 

Sent from my iPad

> On Jun 14, 2017, at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Scalia <jayknowsunix@gmail.com> writes:
>> I've got SSL working without the crl file, but when I set ssl_crl_file to
>> use the one I have, it says FATAL on a restart and no SSL error reported.
>> This is not very helpful.
>
> Did you look into the postmaster log?  Experimenting with an intentionally
> corrupted CRL file here, I get log messages along the lines of
>
> 2017-06-14 16:45:15.096 EDT [22759] LOG:  parameter "ssl_crl_file" changed to "root+client.crl"
> 2017-06-14 16:45:15.102 EDT [22759] LOG:  could not load SSL certificate revocation list file "root+client.crl": bad
base64decode 
>
> The actually useful part of that comes out of OpenSSL, and we don't have
> a lot of control about how specific it is ... but there should be
> *something*.
>
>            regards, tom lane

John Scalia <jayknowsunix@gmail.com> writes:
> Well, it turned out that the CRL was in the wrong format. So, I managed
> to convert it with OpenSSL and it loaded properly. I do have one more
> question... the Treasury Department, which produces these certificates
> for us, expires all the CRL's in just 6 hours,

Ugh.

> so does that mean I'd have to do restart on the database each time I got
> a new one or would a reload work?

As of PG 10, a reload would work, but in prior versions you'll have to
restart to get it to pick up new SSL config files.

If you're feeling desperate you could try back-patching commit de41869b6,
but keep in mind that hasn't made it through a beta-test cycle yet.

            regards, tom lane

Thanks, I'll try to convince the management to upgrade ASAP once 10 makes it into a production release.

Sent from my iPad

> On Jun 14, 2017, at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> John Scalia <jayknowsunix@gmail.com> writes:
>> Well, it turned out that the CRL was in the wrong format. So, I managed
>> to convert it with OpenSSL and it loaded properly. I do have one more
>> question... the Treasury Department, which produces these certificates
>> for us, expires all the CRL's in just 6 hours,
>
> Ugh.
>
>> so does that mean I'd have to do restart on the database each time I got
>> a new one or would a reload work?
>
> As of PG 10, a reload would work, but in prior versions you'll have to
> restart to get it to pick up new SSL config files.
>
> If you're feeling desperate you could try back-patching commit de41869b6,
> but keep in mind that hasn't made it through a beta-test cycle yet.
>
>            regards, tom lane