CODEWITHSUNDEEP
sslssl-certificatelets-encrypt
Carson Cole
Carson Cole

Reputation: 4451

Let's Encrypt SSL certs for same domain, multiple instances

I've successfully installed Let's Encrypt SSL certs on a domain instance (on Ubuntu 14.4), but I now want to install the same certs on another virtual instance for the same domain.

Question: With multiple virtual instances for the same domain, should I just copy over the certs from the initial initial (using the Let's Encrypt tools), or is there another better way?

I imagine that you can't query Let's Encrypt for a new cert, or else it will invalidate the first.

I am currently sharing the certs, which works.

Upvotes: 8

Views: 6526

Answers (2)

Tombart
Tombart

Reputation: 32388

Yes, it's possible. There are at least two options:

  • Run certbot in manual mode

    ./certbot-auto certonly --manual -d example.com

    in this case certbot requires a random file to be served from .well-known/acme-challenge/, e.g.:

    http://example.com/.well-known/acme-challenge/-Y5pUBNKdx5GKSloP3RifHzUW3NT9xt1UAloNkHz7wc

    Now you could distribute the challenged file to all your servers or create a rewrite from all your sites to a single challenge server:

    rewrite ^/.well-known/acme-challenge/(.*)$ http://acme.example.com/$1 redirect;

    acme.example.com should be served from single server with root pointing to /tmp/certbot/public_html/ (or wherever you'll store challenged files).

    Have a look at hooks in certbot manual in order to script this procedure.

  • Use DNS challenge. In this case you'll be asked to add TXT record to your DNS, for example.com domain:

    _acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

    Again, you can automate this using hooks --manual-auth-hook, --manual-cleanup-hook.

Upvotes: 1

Oleg
Oleg

Reputation: 221997

I find the question very interesting from the point of view of common understanding of SSL/TLS certificates. I personally see no general problem in sharing of the same SSL/TLS certificate on multiple computers or virtual instances. The only problem could exist only in some properties of the certificate, like Subject Alternative Name (DNS Name), of the certificate (I mean the options like ).

The section 3.1 (Server Identity) of rfc2818:

If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.)

...

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

The only problem is that Let’s Encrypt seems not yet support wildcard certificates (see FAQ). I'm not sure whether the restriction is still exist and you really can't create Let’s Encrypt with Subject Alternative Name (``) like DNS Name=www.yourdomain.com and DNS Name=*.yourdomain.com. Thus the exact answer on your question could depends on certificate properties.

If you would use the same certificate for two server you could have some additional problem with the usage of session cache of TLS, which improves the performance of TLS and both clients and the server can use the same Session ID, which improves the performance of TLS. You should describe the exact scenario which you use to be able to consider exactly whether you could have some issues in Session ID or not.

Upvotes: 0

Related Questions