so currently we are running a sort of "partial DNS round robin" setup.
We use 3 different NGINX web servers with a bunch of domains, however 6 of those domains are setup so they point to the IP of all 3 web servers.
So my first issue was making Certbot work when creating certificates in round robin (since ACME challenge could hit a web server that didn't host the challenge file, which resulted in failure). I've solved that by creating redirects for ACME challenges to a single web server which acts as an "authenticator".
Now my question is, since now there are 2 separate certificate files in play... One for the domains that are not in the DNS round robin (certs that each webserver creates for the domains hosted on it) and then the cert file that "authenticator server" creates, which includes all of the round robin domains... What would be simplest solution to distribute these certs to other web servers?
Could I just copy the round robin cert to the other web servers and manually merge it with the existing ones? Say something like copy the contents of "fullchain.pem" and "privkey.pem" into existing ones, pretty much merging them?
Related
I've been investigating the possibility of migrating to using Let's Encrypt to maintain the SSL certificates we have in place for the various resources we use for our operations. We have the following resources using SSL certificates:
Main website (www.example.com / example.com) - Hosted and maintained by a 3rd party who also maintains the SSL certificate
Client portal website (client.example.com) - IIS site hosted and maintained by us on a server located in a remote data center
FTP server (ftp.example.com) - WS_FTP Server hosted and maintained by us on a server located in a remote data center
Hardware firewall (firewall.example.com) - Local security appliance for our internal network
Remote Desktop Gateway (rd.example.com) - RDP server hosted and maintained by us on a server located locally
As indicated above, the SSL certificate for the main website (www) is maintained by the 3rd-party host, so I don't generally mess with that one. However, as you can tell, the DNS records for each of these endpoints point to a variety of different IP addresses. This is where my inexperience with the overall process of issuing and deploying SSL certificates has me a bit confused.
First of all, since I don't manage or maintain the main website, I'm currently manually generating the CSR's for each of the endpoints from the server/service that provides the endpoint - one from the IIS server, a different one from the RDP server, another from the WS_FTP server, and one from the hardware firewall. The manual process, while not excessively time-consuming, still requires me to go through several steps with different server systems requiring different processes.
I've considered using one of Let's Encrypt's free wildcard SSL certificates to cover all four of these endpoints (*.example.com), but I don't want to "interfere" with what our main website host is doing on that end. I realize the actual certificate itself is presented by the server to which the client is connecting, so it shouldn't matter (right?), but I'd probably still be more comfortable with individual SSL certificates for each of the subdomain endpoints.
So, I've been working on building an application using the Certes ACME client library in an attempt to automatically handle the entire SSL process from CSR to deployment. However, I've run into a few snags:
The firewall is secured against connections on port 80, so I wouldn't be able to serve up the HTTP-01 validation file for that subdomain (fw.example.com) on the device itself. The same is true for the FTP server's subdomain (ftp.example.com).
My DNS is hosted with a provider that does not currently offer an API (they say they're working on one), so I can't automate the process of the DNS-01 validation by writing the TXT record to the zone file.
I found the TLS-ALPN-01 validation method, but I'm not sure whether or not this is appropriate for the use case I'm trying to implement. According to the description of this method from Let's encrypt (emphasis mine):
This challenge is not suitable for most people. It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns. Right now that mainly means large hosting providers, but mainstream web servers like Apache and Nginx could someday implement this (and Caddy already does).
Pros:
It works if port 80 is unavailable to you.
It can be performed purely at the TLS layer.
Cons:
It’s not supported by Apache, Nginx, or Certbot, and probably won’t be soon.
Like HTTP-01, if you have multiple servers they need to all answer with the same content.
This method cannot be used to validate wildcard domains.
So, based on my research so far and my environment, my three biggest questions are these:
Would the TLS-ALPN-01 validation method be an effective - or even available - option for generating the individual SSL certificates for each subdomain? Since the firewall and FTP server cannot currently serve up the appropriate files on port 80, I don't see any way to use the HTTP-01 validation for these subdomains. Not being able to use an API to automate a DNS-01 validation would make that method generally more trouble than it's worth. While I could probably do the HTTP-01 validation for the client portal - and maybe the RDP server (I haven't gotten that far in my research yet) - I'd still be left with handling the other two subdomains manually.
Would I be better off trying to do a wildcard certificate for the subdomains? Other than "simplifying" the process by reducing the number of SSL certificates that need to be issued, is there any inherent benefit to going this route versus using individual certificates for each subdomain? Since the main site is hosted/managed by a 3rd-party and (again) I can't currently use an API to automate a DNS-01 validation, I suppose I would need to use an HTTP-01 validation. Based on my understanding, that means that I would need to get access/permission to create the response file, along with the appropriate directories on that server.
Just to be certain, is there any chance of causing some sort of "conflict" if I were to generate/deploy a wildcard certificate to the subdomains while the main website still used its own SSL certificate for the www? Again, I wouldn't think that to be the case, but I want to do my best to avoid introducing more complexity and/or problems into the situation.
I've responded to your related question on https://community.certifytheweb.com/t/tls-alpn-01-validation/1444/2 but the answer is to use DNS validation and my suggestion is to use Certify DNS (https://docs.certifytheweb.com/docs/dns/providers/certifydns), which is an alternative managed alternative cloud implementation of acme-dns (CNAME delegation of DNS challenge responses.
Certify DNS is compatible with most existing acme-dns clients so it can be used with acme-dns compatible clients as well as with Certify The Web (https://certifytheweb.com)
I'm migrating servers, moving my sites from VPS A to VPS B. I use Let's Encrypt for all of my 10 website's SSL certificates. Before I start this migration process I need to know issues that I might be running into.
I have used win-acme to create certificates for ALL of my 10 websites on VPS A.
I want to test migrating 1 site, let's call this site X, to VPS B first.
Then after I copied all data for site X from VPS A to VPS B, I want to generate the SSL certificate and change my DNS settings so site X no longer points to VPS A, but to VPS B.
My question is: when I run win-acme on VPS B and generate a new SSL certificate for site X, can I have 2 SSL certificates for the same domain name that were generated for 2 different servers? Or will Let's Encrypt invalidate one of them?
Hopefully my question is clear, any context/further info is highly appreciated!
Already checked here and here.
Let's encrypt uses the ACME protocol the default verification method is based on the server being able to respond to a specific http request (which is only possible if the IP matches).
It is however possible to use DNS certification, win acme has a plugin to do dns verification. I have no experience with win acme, but with certbot DNS verification is automated for some dns providers and requires manual steps for other dns providers.
With DNS verification it's possible that you have a certificate for a domain on multiple servers. With the regular verification it isn't possible.
You could copy the cert to the other server.
Test it by adding you local dns with the new server ip for the domain you have to test.
The copy steps depend on the system you are using.
https://community.letsencrypt.org/t/move-to-another-server/77985
My application domain was bought on GoDaddy, the NS servers point to Route 53. Route53 has A records to Elastic Load Balancers for different urls which manage traffic to my Elastic Beanstalk.
Do I require more than one SSL certificate? Will a wildcard certificate be fine for this scenario (I assume it will be).
The reason I'm confused is because of the setup of the system and a lack of understanding how SSL certificates work with A records and Load Balancers.
A wildcard certificate should be sufficient, but you'll need to use CNAME records to map your subdomains to your various ELBs. A records are a recipe for disaster, because the ELBs change IP frequently.
You'll also need to load your certificate into AWS and create an HTTPS listener for each ELB, which is a lot of fun. See the ELB developer's guide.
This question is a little old, and I wanted to point out that today there is a free way to do this (rather than a wildcard cert which is typically expensive.)
Using Amazon certificate manager, you can request a cert for free, and assign a number of domains and subdomains to it. I have a cert running that has a total of six subdomains across two different domains. Four of the subdomains all point to the same application, with the load balancer on elastic beanstalk application pointing to the one cert.
I'm investigating a little problem for my employer. My company runs a website under an SSL certificate for the domain www.domainone.net.nz (Yes, New Zealand)
However, there's been a high-level marketing decision to change our primary domain to www.domaintwo.co.nz.
So, easy, right? Buy a new SSL cert for www.domaintwo.co.nz and get it running on IIS. Easy.
However, we have a few WebServices published that need to be accessed over HTTPS - there's some systems in place out in the wild that are using https://www.domainone.net.nz/
I would like to run BOTH certs at the same time, and give our partners and clients that are using these WebServices a set timeframe (six months, say) to roll over to the new domain, before revoking the www.domainone.net.nz cert.
This is a bit fiddly to search for - I keep getting explanations of wildcard SSL domains, which wouldn't help in this particular case, as the central domain name has changed.
Is this possible under IIS? My asp.dll shows version 6.0.3790.4195
It's possible, if you have separate IP addresses for both sites, simply create two sites, one with each SSL certificate and point the directories for both sites to the same place.
But with a single website, no it's not possible
you should be able to do this as long as you have two different IP's one for each of the SSL Certs, you may have to set up two sites that point to the same location to get it working properly, but im not sure.
Here is my scenario:
default website on IIS 6.0 is already protected by an SSL cert with common names covering the following:
domainname.com
www.domainname.com
I have a new website on the same IIS server and need to protect it with an SSL cert with the following common name:
subdomainname.domainname.com (same domainname as default)
I do not have the freedom to add a new IP address to the server. Not an infrastructure friendly request for whatever reasons.
We also have our Exchange webmail protected by another cert on another server with:
webmail.domainname.com
I do not believe I can use a wildcard cert because exchange is on a different server, correct?
Whether I can or not use a wildcard server, how can I protect the new subdomain on the main IIS server with a new cert? Do I replace the cert on the default with the new common name representing the subdomain web site and the default web site common names. Can I assign the same cert on the same server with all common names needing protection to multiple websites on IIS 6.0?
Thanks for any help in getting this resolved.
You are correct, you would need multiple signed certificates for your servers. Godaddy offers certs for single-servers only, AFAICT. DigiCert offers multi-domain, multi-server certificates. I've never used them, so I can't vouch for anything they offer, but it shows that what you want IS available in the marketplace.
You can get a single cert and use it on multiple servers so long as the DNS entries map out to the correct servers.
Go Daddy offers several cert types and they don't make it clear how to deal with this issue.
Standard (Turbo) SSL 1 domain ~$30
Standard Multiple Domain (UCC) SSL Up to 5 Domains ~$90
Standard (Turbo) Wildcard SSL ~$200
Get the 5 domain cert with
domainname.com
www.domainname.com
subdomainname.domainname.com
webmail.domainname.com
all listed on the one cert. Complete the request on the server you started the request from then use the tools built into the windows servers to copy the cert from one server to another. Doing so doesn't remove it from the first server and adds it to the second.
I did this not too long ago. My Web server is 2008 and the mail server is 2003. In that combination I had to export as a .pfx file and then import the .pfx. If you do it from 2003 to 2003 you may be able to use the copy from another server option and save manually moving the exported file around.
In my case the cert mentions "Certificate Subject Alt Name" with
Not Critical
DNS Name: www.adomain.com
DNS Name: adomain.com
DNS Name: www.adomain.com
DNS Name: mail.adomain.com
Looks like one of those lines is a duplicate but hey it works. I don't know why the cert uses the terminology of "Not Critical" to head that section.
IIS won't let you put two sites on the same IP/port combo but it will let you put the same SSL on two different sites. The secondary site will have to use something other than 443 if you don't have the option of using a different IP address.