It is an honor to be featured in Gartner 2019 Magic Quadrant for Datacenter Backup and Recovery Solutions. Gartner’s MQ sets a high standard and earning a place on their grid is a great affirmation that Acronis is delivering on our mission to protect all data, apps, and systems.
SSL Solution for Multi Domain / Multi Host
I need to secure a couple websites, and am looking for the ideal SSL solution to handle multiple domain names / multiple hosts. Here is a breakdown of my topology.
Website 1 - Self hosted IIS server. This server has multiple IP addresses (3 different ISP connections) and host names, but all point to the same exact virtual machine, aside from a replica that is stored at a remote location, but would need to be able to come online as a failover.
website1a.com - points to 1.1.1.1 (onsite IIS Server)
website1b.com - points to 2.2.2.2 (onsite IIS Server)
website1c.com - points to 3.3.3.3 (onsite IIS Server)
website1d.com - points to 4.4.4.4 (offsite backup of IIS server)
Website 2 (Wordpress) - GoDaddy VPS hosted, with Name Cheap backup website
website2.com - points to 5.5.5.5 when there is a fail over, I auto redirect the DNS for website2.com to go to NameCheap Hosting 6.6.6.6
I was thinking about purchasing a single SAN SSL that includes every domain. However, I am not sure I will be able to install that SSL on the IIS server, as well as the go-daddy and name-cheap hosting.
Looking for advise.
Thanks in advance!!
Dan
Website 1 - Self hosted IIS server. This server has multiple IP addresses (3 different ISP connections) and host names, but all point to the same exact virtual machine, aside from a replica that is stored at a remote location, but would need to be able to come online as a failover.
website1a.com - points to 1.1.1.1 (onsite IIS Server)
website1b.com - points to 2.2.2.2 (onsite IIS Server)
website1c.com - points to 3.3.3.3 (onsite IIS Server)
website1d.com - points to 4.4.4.4 (offsite backup of IIS server)
Website 2 (Wordpress) - GoDaddy VPS hosted, with Name Cheap backup website
website2.com - points to 5.5.5.5 when there is a fail over, I auto redirect the DNS for website2.com to go to NameCheap Hosting 6.6.6.6
I was thinking about purchasing a single SAN SSL that includes every domain. However, I am not sure I will be able to install that SSL on the IIS server, as well as the go-daddy and name-cheap hosting.
Looking for advise.
Thanks in advance!!
Dan
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
What are your doubts? There should not be a problem to use a single certificate with multiple SANs on the IIS.
If you only need DV certificates try Lets Encrypt. The renewal process can be easily done using certbot f.e.
Just use https://LetsEncrypt.org generating a separate cert for each site or one cert to cover them all.
Tip: Using one cert to cover many domains/hosts will cause you all manner of complexity + problems over time. Better for each cert to cover only one domain or host. Or use a wildcard LetsEncrypt cert to cover all hosts on one domain.
So to cover one domain...
Then a CRON job to auto-renew all certs on one machine forever...
Tip: Using one cert to cover many domains/hosts will cause you all manner of complexity + problems over time. Better for each cert to cover only one domain or host. Or use a wildcard LetsEncrypt cert to cover all hosts on one domain.
So to cover one domain...
certbot-auto certonly --no-self-upgrade --non-interactive --rsa-key-size 4096 --email $email --agree-tos --webroot -w $dir -d $domain -d www.$domain
Then a CRON job to auto-renew all certs on one machine forever...
0 1 * * * (echo '#####' && date && certbot-auto renew --non-interactive --post-hook "service apache2 reload") >> /var/log/ssl-renewals.log 2>&1
Best to open a separate question about how to do failover design as what you're describing might work (notice I said might) only if you have no databases involved.
If there are any databases, SQL or other, then your first step will be to determine how to sync up data between all nodes.
This can be a very long discussion, best done in a separate question.
If there are any databases, SQL or other, then your first step will be to determine how to sync up data between all nodes.
This can be a very long discussion, best done in a separate question.
There is a SQL server associated with the IIS website on site. The fail over site is a complete replica of the production environment. All VM's are replicated daily (Including SQL). So outside of the IP changing on a fail over, I would presume I wouldn't have any issues. But I am not positive, and my experience with securing sites with SSL is minimal so I wanted to confirm with you experts :)
I will start a new question starting with securing the IIS website, then open another question about securing the GoDaddy hosted website after. These are two completely separate systems.
I will start a new question starting with securing the IIS website, then open another question about securing the GoDaddy hosted website after. These are two completely separate systems.
No problems related to SSL.
So long as you have the correct certs associated with correct sites on correct IP all will be well.
Even if you change a site's IP (best to use short 5-10 minute TTLs for your setup), there will be some period of time (<TTL seconds) where some visitors may see different IPs.
This is also no problem, because certs living on each instance will be correct for the IP where they're running.
I generally use wildcard certs for this exact reason. I can generate the certs on the DNS instance (as zone file access is usually required), then pull the wildcard certs from the DNS instance to any number of machines or containers, allowing extremely complex setups to be maintained with zero human intervention (once setup is working).
So long as you have the correct certs associated with correct sites on correct IP all will be well.
Even if you change a site's IP (best to use short 5-10 minute TTLs for your setup), there will be some period of time (<TTL seconds) where some visitors may see different IPs.
This is also no problem, because certs living on each instance will be correct for the IP where they're running.
I generally use wildcard certs for this exact reason. I can generate the certs on the DNS instance (as zone file access is usually required), then pull the wildcard certs from the DNS instance to any number of machines or containers, allowing extremely complex setups to be maintained with zero human intervention (once setup is working).
Premium Content
You need an Expert Office subscription to comment.Start Free Trial