When working with HP blade chassis systems, administrators often face a peculiar limitation - the web interface only allows generating Certificate Signing Requests (CSRs) with a single Subject Alternative Name (SAN). This becomes problematic when you need to secure multiple DNS names for the same service.
Common workarounds like generating the CSR externally or adding SANs during signing won't work here because:
- The blade chassis won't accept externally generated private keys
- Your CA might not support adding SANs during the signing process
Here's how you can modify an existing CSR to include additional SANs:
# First, extract the existing CSR to view its contents
openssl req -in original.csr -noout -text
# Create a custom OpenSSL configuration file (san.cnf)
[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
[ req_distinguished_name ]
# Fill in your existing DN fields here
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
organizationName = Organization Name
commonName = Common Name
[ v3_req ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = primary.hostname.com
DNS.2 = secondary.hostname.com
DNS.3 = backup.hostname.com
Now regenerate the CSR while preserving the original key:
openssl req -new -key original.key -out modified.csr -config san.cnf
Always verify your modified CSR contains all required SANs:
openssl req -in modified.csr -noout -text | grep -A 1 "Subject Alternative Name"
Some CAs might require specific formatting for SAN extensions. You might need to adjust your approach based on:
- CA's accepted SAN formats
- Maximum allowed SAN count
- Specific naming conventions
If modifying the CSR isn't feasible, consider this alternative workflow:
- Generate CSR through HP interface with one SAN
- Obtain certificate from CA
- Create a new CSR with all required SANs
- Request re-key from CA while presenting original cert
Many administrators working with HP blade chassis face a frustrating limitation - the web interface only allows generating Certificate Signing Requests (CSRs) with a single Subject Alternative Name (SAN). This becomes problematic when you need multiple SANs for proper certificate functionality.
The situation presents several technical constraints:
- CSRs must be generated through the blade chassis web interface
- Private keys cannot be imported externally
- The CA won't add SANs during signing
- Only one SAN field is available in the web form
While you can't directly edit the CSR in the blade chassis interface, you can modify the CSR file after generation but before submitting it to your CA. Here's how:
# Extract the original CSR
openssl req -in original.csr -noout -text
# Create a new OpenSSL config file (san.cnf) with:
[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
CN = bladesystem8.services.adelaide.edu.au
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = bladesystem8
DNS.2 = bladesystem8.services.adelaide.edu.au
DNS.3 = bladesystem8-backup
DNS.4 = bladesystem8-backup.services.adelaide.edu.au
The critical part is maintaining the original private key while creating a new CSR with additional SANs:
# First, extract the private key from the blade chassis
# (This might require using the chassis backup/export functionality)
# Then generate new CSR with the same key:
openssl req -new -key original.key -out modified.csr -config san.cnf
Before submitting to your CA, verify the new CSR contains all required SANs:
openssl req -in modified.csr -noout -text | grep -A 1 "Subject Alternative Name"
If CSR modification isn't possible, another approach is to request a certificate with the single SAN, then create a new certificate with additional SANs using the same key:
openssl x509 -req -in original.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
-out certificate.crt -days 365 -extfile san_ext.cnf -extensions v3_ca
# Where san_ext.cnf contains:
[ v3_ca ]
subjectAltName = DNS:bladesystem8,DNS:bladesystem8.services.adelaide.edu.au,DNS:bladesystem8-backup,DNS:bladesystem8-backup.services.adelaide.edu.au
- Always maintain proper key security during this process
- Test the modified certificate thoroughly in your environment
- Document the process for future reference
- Consider automating the process if you need to do this frequently