You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 7, 2023. It is now read-only.
I was trying to run go-openssl under Windows and got in trouble with the server certificate and private key files to be loaded by the openssl.ListenAndServeTLS() function. Instead of starting up normally, the server process ended immediately with the following error: No PEM certificate found in 'server.crt'. At the end, it turned out that the only problem were the CRLF line endings in the server certificate and private key files. After having changed then to LF, everything worked like a charm.
Nevertheless, this is a non-obvious pitfall making go-openssl somewhat difficult to use under Windows. It therefore would be preferable to make it happen that PEM files used regardless whether their line ending is LF or CRLF. This seems also to be a common practice for most other TLS/SSL applications and libraries.
The text was updated successfully, but these errors were encountered:
@stephaneberle9 merged your PR, but the regex that allows for arbitrary space and hyphens seems non-spec compliant #12 which we'll try and fix up before doing a release.
I was trying to run go-openssl under Windows and got in trouble with the server certificate and private key files to be loaded by the
openssl.ListenAndServeTLS()
function. Instead of starting up normally, the server process ended immediately with the following error:No PEM certificate found in 'server.crt'
. At the end, it turned out that the only problem were the CRLF line endings in the server certificate and private key files. After having changed then to LF, everything worked like a charm.Nevertheless, this is a non-obvious pitfall making go-openssl somewhat difficult to use under Windows. It therefore would be preferable to make it happen that PEM files used regardless whether their line ending is LF or CRLF. This seems also to be a common practice for most other TLS/SSL applications and libraries.
The text was updated successfully, but these errors were encountered: