Home / server / Questions / 253960
In Process
Jason Tan
Asked: 2011-03-31 19:32:13 +0800 CST

Adding Subject Alternate Names (SAN) to an existing Cert Signing Request (CSR)

  • 772

Can any one tell me how I an add a number of Subject Alternate Names to an existing CSR?

I'm not talking about generating a CSR with SANs or adding SANs at signing time - I know how to do both of these things.

Background: The problem we have is that HP blade chassis, allow you to generate CSRs, but they only allow a single SAN. We can't use a CSR generated elsewhere as we could not use the resultant cert as there is no way (that I can find) to upload the key to the blade chassis.

Our CA's standard process does not allow for adding SANs are signing time. They are willing to experiment, however I am trying to find a solution at our end as this will mean we won't have to rely on them having a non standard process for us - in my experience if they need to use a non standard process life will eventually get difficult. E.g. when a staff member who knows the non standard process is not present due to leave etc.

Current method is to connect to the bladechassis onboard admin via the web gui and generate the CSR with a single CN.

The web gui only allows for a single SAN in the CSR.

Then we self sign it with the following stanza in the openssl config:

[ v3_ca ]
subjectAltName = "DNS:bladesystem8,DNS:bladesystem8.services.adelaide.edu.au,DNS:bladesystem8-backup,DNS:bladesystem8-backup.services.adelaide.edu.au"

The resultant cert has the extra SANs.

certificate csr subject-alternative-names

3 Answers

  1. If your chassis doesn't support adding SANs, you'll need to get the key off the chassis and generate the CSR with openssl.

    Make sure req_extensions = v3_req is uncommented in the [ req ] section.

    Add the subjectAltName to the [ v3_req ] section.

    Generate a new CSR.

    openssl req -new -key extracted_c7000.key -out your_new.csr

    You cannot edit an existing CSR.

    • 16

  2. While cakemox's answer is definitely the easiest if you can somehow get a copy of the private key, there's another way if you can't by basically re-signing the CSR using an "Enrollment Agent" certificate.

    This blog post has all of the nitty gritty details. But the high level overview of the process looks like this:

    • Acquire an Enrollment Agent Certificate
    • Modify an SSL certificate template to require an EA certificate for issuance
    • Acquire a CSR that needs SAN Information
    • Use the EA certificate to resign the CSR while adding the SAN information

    When I tried this personally, I'm pretty sure I skipped the part about modifying the certificate template. Presuming you can generate an Enrollment Agent cert for yourself, the actual process looks something like this.

    Create a san.inf with the SAN extension info in it

    [Extensions]
2.5.29.17="{text}dns=mysan1.example&dns=mysan2.example"

    Re-sign the request

    certreq -policy -config "myca.example\CA" orig-request.csr san.inf corrected-request.csr

    Submit the corrected request

    certreq -submit -config "myca.example\CA" -attrib "CertificateTemplate:MyTemplate" corrected-request.csr

    And then proceed as normal with the issuance process.

    • 2

  3. Important note: All of this is somewhat speculative, so if you're deep in the code and it doesn't agree with what I'm saying, believe the code. I'm not a CA expert, I just play one on TV. That said:

    As a feature of CSRs, it'll be tough. The final step in generating a CSR programmatically is to hash everything you've created, and then sign it with the private key. So, while you could add those attributes to the text of the CSR, the the signature wouldn't match up with the contents, so no CA would sign it.

    In your case, though, you control (or are at least in contact with) the CA. This gives you two options:

    1. You can instruct the CA to blithely ignore the signature on the CSR and to issue a cert anyway.
    2. You can have the CA issue a different cert than what is requested (e.g. by adding attributes).

    Of these, #1 seems by far the easiest. You'll need to break the tamper-evident seal on OpenSSL to get it to do this, but it has some functions that should make quite a bit easier. I'd start with asn1parse, which will show you how to break apart the CSR.

    • 0