Windows .Crl to .Pem for Nginx

nginx fails to load ssl certificate

You should never share your private key. You should consider the key you posted here compromised and generate a new key and signing request.

You have a certificate request and not an actual signed certificate. You provide the request ('CSR') to the signing party. They use that request to create a signed certificate ('CRT') which they then make available to you. The key is never disclosed to anyone.

How to get .pem file from .key and .crt files?

Your keys may already be in PEM format, but just named with .crt or .key.

If the file's content begins with -----BEGIN and you can read it in a text editor:

The file uses base64, which is readable in ASCII, not binary format. The certificate is already in PEM format. Just change the extension to .pem.

If the file is in binary:

For the server.crt, you would use

openssl x509 -inform DER -outform PEM -in server.crt -out server.crt.pem

For server.key, use openssl rsa in place of openssl x509.

The server.key is likely your private key, and the .crt file is the returned, signed, x509 certificate.

If this is for a Web server and you cannot specify loading a separate private and public key:

You may need to concatenate the two files. For this use:

cat server.crt server.key > server.includesprivatekey.pem

I would recommend naming files with "includesprivatekey" to help you manage the permissions you keep with this file.

Convert .pem to .crt and .key

I was able to convert pem to crt using this:

openssl x509 -outform der -in your-cert.pem -out your-cert.crt

Generate OpenSSL CRL file without a configuration file

It doesn't seem like this is possible. I have found some other guides to get this working with a configuration file (and generating a new CA):

NGinx SSL certificate authentication signed by intermediate CA (chain)

Edit: I had also this "problem", solution and explanation is at the bottom of the text.

It seemed like nginx doesn't support intermediate certificates. My certs self created: (RootCA is selfsigned, IntrermediateCA1 is signed by RootCA, etc.)

RootCA -> IntermediateCA1 -> Client1 
RootCA -> IntermediateCA2 -> Client2

I want to use in nginx "IntermediateCA1", to allow access to site only to owner of the "Client1" certificate.

When I put to "ssl_client_certificate" file with IntermediateCA1 and RootCA, and set "ssl_verify_depth 2" (or more) , clients can login to site both using certificate Client1 and Client2 (should only Client1).
The same result is when I put to "ssl_client_certificate" file with only RootCA - both clients can login.

When I put to "ssl_client_certificate" file with only IntermediateCA1, and set "ssl_verify_depth 1" (or "2" or more - no matter) , it is imposible to log in, I get error 400. And in debug mode i see logs:

verify:0, error:20, depth:1, subject:"/C=PL/CN=IntermediateCA1/",issuer: "/C=PL/CN=RootCA/"
verify:0, error:27, depth:1, subject:"/C=PL/CN=IntermediateCA1/",issuer: "/C=PL/CN=RootCA/"
verify:1, error:27, depth:0, subject:"/C=PL/CN=Client1/",issuer: "/C=PL/CN=IntermediateCA1/"
client SSL certificate verify error: (27:certificate not trusted) while reading client request headers, (..)

I thing this is a bug. Tested on Ubuntu, nginx 1.1.19 and 1.2.7-1~dotdeb.1, openssl 1.0.1.
I see that nginx 1.3 has few more options about using client certificates, but I'dont see solution to this problem.

Currently, the only one way to separate clients 1 and 2 is to create two, selfsigned RootCAs, but this is only workaround..

Edit 1:
I've reported this issue here:

Edit 2"
*Ok, it's not a bug, it is feature ;)*

I get response here:
It is working, you must only check what your ssl_client_i_dn is (. Instead of issuer you can use also subject of certificate, or what you want from

This is how certificate verification works: certificate must be
verified up to a trusted root. If chain can't be built to a trusted
root (not intermediate) - verification fails. If you trust root - all
certificates signed by it, directly or indirectly, will be
successfully verified.

Limiting verification depth may be used if you
want to limit client certificates to a directly issued certificates
only, but it's more about DoS prevention, and obviously it can't be
used to limit verificate to intermediate1 only (but not

What you want here is some authorization layer based
on the verification result - i.e. you may want to check that client's
certificate issuer is intermediate1. Simplest solution would be to
reject requests if issuer's DN doesn't match one allowed, e.g.
something like this (completely untested):

[ Edit by me, it is working correctly in my configuration ]

server {
listen 443 ssl;

ssl_certificate ...
ssl_certificate_key ...

ssl_client_certificate /path/to/ca.crt;
ssl_verify_client on;
ssl_verify_depth 2;

if ($ssl_client_i_dn != "/C=PL/CN=IntermediateCA1/") {
return 403;

Howto create a certificate using openssl including a CRL distribution point?

openssl x509 does not read the extensions configuration you've specified above in your config file.

You can get the crlDistributionPoints into your certificate in (at least) these two ways:

  1. Use openssl ca rather than x509 to sign the request. Pass -config as needed if your config is not in a default location. Most of your provided command can be used if you omit the options starting with -CA

    openssl ca -in $NAME.csr -out certs/$NAME.pem -days 3650

  2. Use the command as you've provided in your question, but first create a file containing your v3 extensions (ie mycrl.cnf); add the option -extfile mycrl.cnf to your call to openssl x509

    openssl x509 -req -in $NAME.csr -out certs/$NAME.pem -days 3650 \
    -CAcreateserial -CA cacert.pem -CAkey private/cakey.pem \
    -CAserial serial -extfile mycrl.cnf`

    Where mycrl.cnf contains the following:


openssl ca is probably the command better suited to what you want to do, since most examples you will find rely on that command utilizing various settings in openssl.cnf for v3 extensions.

An aside: it is inadvisable to use MD5 message digest in certificates.

Previously SHA1 was the suggested alternative to MD5, however that too is now becoming deprecated. You can specify the message digest used in requests and signing operations, and you can list the supported message digests with openssl list-message-digest-commands.

As an example, you can use SHA256 when signing a request with the -md sha256 option to openssl ca ( or setting default_md=sha256 in your [CA_default] config section).

Related Topics

Leave a reply