Обсуждение: 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