22

I'm running a server "myserver.net", which has the subdomains "a.myserver.net" and "b.myserver.net".

When creating (self-signed) SSL certificates, I have to create one for every subdomain, containing the FQDN, even though those subdomains are just vhosts.

OpenSSL permits only one "common name", which is the domain in question. Is there any possibility to create a certificate that is valid for all subdomains of a domain?

28

Yes, use *.myserver.net as common name.

This is called wildcard certs and there are large number of howtos finding with this keyword.

Here is one of them: https://web.archive.org/web/20140228063914/http://www.justinsamuel.com/2006/03/11/howto-create-a-self-signed-wildcard-ssl-certificate

Update: if you want cert to match root domain as well (myserver.net), then you should use Subject Alternative Name extension. When generating cert using openssh enter '*.myserver.net/CN=myserver.net' as Common Name.

Compatibly is good enough, unless you have an ancient browser.

3
1

Just as an FYI, there is another kind of certificate as well called a Unified Communications Certificate. A wildcard can only be issued for *.domain.com but a UCC certificate allows you to list up to 100 Fully Qualified Domain Names(FQDN) under any domain. The main reason to get one of these is that Microsoft isn't too keen on the wildcards for things like MS Domain controllers, Exchange, etc.

https://www.godaddy.com/help/what-is-a-multiple-domain-ucc-ssl-certificate-3908

A Unified Communications Certificate (UCC) is an SSL certificate that secures multiple domain names and multiple host names within a domain name. A UCC lets you secure a primary domain name and up to 99 additional Subject Alternative Names (SANs) in a single certificate. UCCs are ideal for Microsoft® Exchange Server 2007, Exchange Server 2010, and Microsoft Live® Communications Server.

UCCs are compatible with shared hosting. However, the site seal and certificate "Issued To" information will only list the primary domain name. Please note that any secondary hosting accounts will be listed in the certificate as well, so if you do not want sites to appear 'connected' to each other, you should not use this type of certificate.

The main downside to UCC is that you have to list all your domains up front (wildcards don't require this). If the list ever changes you'll have to get a new certificate. Incidentally, Namecheap (only one I know of that does this) offers an Extended Validation UCC(you pay per domain, which means a 100 domain certificate is VERY expensive), which is the only way to have an EV certificate for more than one domain, as nobody offers EV Wildcards.

0

I can`t comment so I add a separate answer. I tried to create a self-signed certificate for NGINX and it was easy, but when I wanted to add it to Chrome white list I had a problem. And my solution was to create a Root certificate and signed a child certificate by it.

So step by step. Create file config_ssl_ca.cnf Notice, config file has an option basicConstraints=CA:true which means that this certificate is supposed to be root.

This is a good practice, because you create it once and can reuse.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=root region
localityName=root city
organizationName=Market(localhost)
organizationalUnitName=roote department
commonName=market.localhost
emailAddress=root_email@root.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:true
subjectKeyIdentifier = hash
subjectAltName = @alternate_names

Next config file for your child certificate will be call config_ssl.cnf.

[ req ]
default_bits = 2048

prompt = no
distinguished_name=req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
countryName=UA
stateOrProvinceName=Kyiv region
localityName=Kyiv
organizationName=market place
organizationalUnitName=market place department
commonName=market.localhost
emailAddress=email@market.localhost

[ alternate_names ]
DNS.1        = market.localhost
DNS.2        = www.market.localhost
DNS.3        = mail.market.localhost
DNS.4        = ftp.market.localhost
DNS.5        = *.market.localhost

[ v3_req ]
keyUsage=digitalSignature
basicConstraints=CA:false
subjectAltName = @alternate_names
subjectKeyIdentifier = hash

The first step - create Root key and certificate

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365 -config config_ssl_ca.cnf

The second step creates child key and file CSR - Certificate Signing Request. Because the idea is to sign the child certificate by root and get a correct certificate

openssl genrsa -out market.key 2048
openssl req -new -sha256 -key market.key -config config_ssl.cnf -out market.csr

Open Linux terminal and do this command

echo 00 > ca.srl
touch index.txt

The ca.srl text file containing the next serial number to use in hex. Mandatory. This file must be present and contain a valid serial number.

Last Step, crate one more config file and call it config_ca.cnf

# we use 'ca' as the default section because we're usign the ca command
[ ca ]
default_ca = my_ca

[ my_ca ]
#  a text file containing the next serial number to use in hex. Mandatory.
#  This file must be present and contain a valid serial number.
serial = ./ca.srl

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./

# the file containing the CA certificate. Mandatory
certificate = ./ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 365

# a section with a set of variables corresponding to DN fields
policy = my_policy

# MOST IMPORTANT PART OF THIS CONFIG
copy_extensions = copy

[ my_policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = market.localhost
organizationalUnitName = optional
commonName = supplied

You may ask, why so difficult, why we must create one more config to sign child certificate by root. The answer is simple because child certificate must have a SAN block - Subject Alternative Names. If we sign the child certificate by "openssl x509" utils, the Root certificate will delete the SAN field in child certificate. So we use "openssl ca" instead of "openssl x509" to avoid the deleting of the SAN field. We create a new config file and tell it to copy all extended fields copy_extensions = copy.

openssl ca -config config_ca.cnf -out market.crt -in market.csr

The program asks you 2 questions:

  1. Sign the certificate? Say "Y"
  2. 1 out of 1 certificate requests certified, commit? Say "Y"

In terminal you can see a sentence with the word "Database", it means file index.txt which you create by the command "touch". It will contain all information by all certificates you create by "openssl ca" util. To check the certificate valid use:

openssl rsa -in market.key -check

If you want to see what inside in CRT:

openssl x509 -in market.crt -text -noout

If you want to see what inside in CSR:

openssl req -in market.csr -noout -text 
-1

It's a valid question. Unfortunately from what I understand the protocols never intended the owner of a domain to be able to sign certificates for just subdomains.

You are either a CA for anything or nothing. There is no limitation in scope once you are a CA.

Stupid but that's the way it is. Just buy a separate certificate for every single domain that you own $$$, that's right every single one, so don't bother trying to secure embedded devices that you sell.

1
  • 2
    No, this is wrong. First, see the other answer here, second, read up on what a certificate authority actually is. I have a CA for my internal domain only. There very much are scope limitations for CAs. – HopelessN00b Oct 11 '12 at 14:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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