Thread: cannot load server.crt
9.1.3 on Linux . . .
We use our own CA implementation inside Java to generate a PEM-encoded certificate chain (server.crt) and key (server.key).
The certificates are, as they should be, base-64 encoded and surrounded by the appropriate delimiters such as
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
They are also line-wrapped at 77 characters.
But the line wrapping code can cause an extra newline char following the final base-64 encoded character of the cert or key, and before the -----END CERTIFICATE----- delimiter.
When this happens, Postgres rejects the certificate.
-----BEGIN CERTIFICATE-----
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
. . .
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah
-----END CERTIFICATE-----
Although these formats are imprecisely defined, we think Postgres should accept such a certificate since both Java keytool and Windows certificate management accept the certificate as valid.
Is this a bug in OpenSSL and/or Postgres ?
-dvs-
"Sahagian, David" <david.sahagian@emc.com> writes:
> We use our own CA implementation inside Java to generate a PEM-encoded certificate chain (server.crt) and key
(server.key).
> The certificates are, as they should be, base-64 encoded and surrounded by the appropriate delimiters such as
> -----BEGIN CERTIFICATE-----
> -----END CERTIFICATE-----
> They are also line-wrapped at 77 characters.
> But the line wrapping code can cause an extra newline char following the final base-64 encoded character of the cert
orkey, and before the -----END CERTIFICATE----- delimiter.
> When this happens, Postgres rejects the certificate.
That would be OpenSSL rejecting the cert; Postgres never touches such
files directly. I don't know whether there's an official spec about
the contents of cert files, but you'd have to take it up with the
OpenSSL folk if you want to lobby for a change in this behavior.
regards, tom lane