Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Here's a background of what I've done so far:

  • I've been able to add a CRL to a self signed certificate using OpenSSL (see attached). But I'm not sure how to create an X.509 certificate issued by this self-signed root (i.e. a leaf certificates from this CA)

  • I've tried to create a leaf certificate from this CA using openssl req -new -nodes -out leafcert.pem -keyout private/leaf-key.pem -days 365, but I haven't been able to determine if the CRL is in this certificate... I've used the openSSL command:

openssl req -text -noout -verify -in leafcert.pem

But all I can see is the following:

verify OK
Certificate Request:
        Version: 0 (0x0)
        Subject: C=US, ST=DC, L=Washington, O=Norkie, OU=Test, CN=Leaf/emailAddress=first.last@domain.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                Exponent: 65537 (0x10001)
            challengePassword        :akronohio
    Signature Algorithm: sha1WithRSAEncryption

It doesn't tell me who the leaf is issued by and if it has any crlDistributionPoints.

share|improve this question
Not sure you want to make this e-mail address public on this site... You may want to edit that. What goes into the certificate depends vastly on the OpenSSL configuration (the content of openssl.cnf). There is nothing to indicate that you've added a crlDistributionPoints extension here. –  Bruno Apr 30 '12 at 18:04
I know. That's why I asked the question. Is there a command to display all extensions and the issuer? –  David De Groot Apr 30 '12 at 18:23
The command you've used is correct, it displays the attributes in the CSR, they're just not in there. In addition, CSRs don't have issuers (nor validity dates): these are the main technical differences with X.509 certs. –  Bruno Apr 30 '12 at 18:29

1 Answer 1

up vote 3 down vote accepted

The content of the request barely matters. It's the content of the resulting certificate that counts.

No self-respecting CA (and hopefully none of those that are bundled by default with our browsers) should copy attributes in the CSR into the certificate without vetting them by another way. Therefore, there is little point in putting attributes in the CSR itself for CAs, since they really should decide what goes in by another means. (I've actually tried once to add extra extensions to a CSR and the commercial CA I used stripped them away and only put in what they said they would in accordance to the application form, quite rightly. Most of the time, they'll also remove the RDNs in your Subject DN for which they cannot vouch for, e.g. O= for a Domain Validated certificate.)

If you really want extensions in your request, turn in on in your openssl.cnf file (you may also have to use the -reqexts option with the openssl req command):

req_extensions = v3_req

(and fill in the corresponding [v3_req] section).

To issue End-Entity Certificates with the CRL distribution attributes, you need to add this to the openssl.cnf file.

(I'm assuming you have a copy of openssl.cnf in your current directory)

You'll be able to get your crlDistributionPoint extension as follows:

  • Add this line to the [ v3_custom ] section:

    crlDistributionPoints = URI:http://example.com/my.crl
  • Make the issuing process use these extensions:

    openssl x509 -req -days 365 -in file.csr \
                 -signkey ca.key -out file.crt \
                 -extfile openssl.cnf -extensions v3_custom
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.