We have a single server and want to have multiple domains pointing to that server via SSL. Tried to do the following in GCP (two different approaches):
Approach 1:
Setup a classic load balancer
Create a frontend service with port 443.
Create a Google managed certificate.
Add multiple domains to that certificate (a.domain1.com, b.domain1.com, a.domain2.com)
Setup Backend service.
Save
The loadbalancer spins up correctly, but we have the following issues:
SSL for a.domain1.com and b.domain1.com gets created, but SSL for a.domain2.com fails with the error FAILED_NOT_VISIBLE. All these are domains are setup correctly with DNS entries.
When I visit https://a.domain1.com, Chrome throws an error saying:
This site can't provide a secure connection, uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Approach 2:
Create multiple Frontends and add self managed SSL for each of them individually.
In this case, when I visit t1.domain2.com, chrome throws an error saying this certificate is invalid and pointing to t1.domain1.com
Question:
Any idea what I am doing wrong here? In GCP, is it possible to have a single backend service having multiple frontends pointing to it via SSL?
Related
I have a domain purchased at 1and1 and set up at AWS EC2 with SSL and Apache server.
Even the domain pointing to the correct IP (using nslookup I can see it), it works from some places and not from others.
For example, here from my workplace, I see this page (the domain does not reach the EC2 server):
I launched a Windows EC2 at AWS to make a test and from there, everything is correct (the page loads and SSL is valid):
From my client's computer, it has another behavior. It reaches the EC2 server, but is says the SSL is invalid:
Has anyone faced the same problem?
The first thing you need to do is get an Elastic IP, the instance IP can change during reboot etc but elastic IP are static IP’s so you should make sure you create one of them and assign it your running instance.
Create Hosted Zone and Record Sets
Documentation is here - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingHostedZone.html
Create a recordset and add values
Add the Amazon NameSpaceServers in Control panel of Domain Provider
Import the SSl certificate to AWS Certificate manager (Optional). Documentation is here https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-api-cli.html#import-certificate-api
Self signed certificate will not work.
Deploy the SSl certificate into Apache server and configure the traffic for https.
Open the AWS in-bond traffic port documentation is here - https://aws.amazon.com/premiumsupport/knowledge-center/connect-http-https-ec2/
Im currently building an application that will reside at app.mydomain.com which is running on Heroku. All users will have their own entry points, like app.mydomain.com/client1, app.mydomain.com/client2, etc. I want clients to be able to setup their own domain (www.clientdomain.com) and cname it to their entry point. I understand this is pretty straight forward up until now.
All my DNS is handled by Cloudflare and I believe I can configure Cloudlfare into Full (Strict) mode, all I need to do is install their Origin Cert onto my Heroku dyno. This will ensure that all direct connects to my domain will be secure (going to app.mydomain.com/client1).
Question is, how does a client go about getting an SSL'ed connection for their domain; do I need to get a multidomain cert and start adding domains to it as I get clients, or am i supposed to install their cert onto Heroku (I believe I can only install 1 so thats a no go) or is it supposed to live on Cloudflare somewhere, or are there additional options I'm not seeing (I hope there are!).
Im not wondering what to do for my own domains, but rather, how do clients setup an SSL connection with their domains that resolve onto my servers.
This is rather perplexing!
The flow would be (I think):
User Browser -> Clients DNS -> (cname to) My Cloudflare -> Heroku
Hmm, it looks like this might be a pretty solid solution to this issue...
https://blog.cloudflare.com/introducing-ssl-for-saas/
Edit - after clarification
I'm currently building an application that will reside at
app.mydomain.com which is running on Heroku. All users will have their
own entry points, like app.mydomain.com/client1,
app.mydomain.com/client2, etc. Question is, how does a client go about
getting an SSL'ed connection for their domain; do I need to get a
multidomain cert and start adding domains to it as I get clients?
If you are going to use the same Heroku app for all of your clients (I think this is a bad idea by the way, but you might be required to) - then yes - you should get a multi-domain certificate and keep adding domains to it as your list of clients expand.
Original answer - which explains SSL + Load Balancing on Heroku.
Im currently building an application that will reside at
app.mydomain.com which is running on Heroku. I was clients to be able
to setup their own domain www.clientdomain.com and cname it to mine.
You will need a wildcard certificate to cover your subdomain (for the app.mydomain.com). You'll have use that cert in heroku.
...all I need to do is install their Origin Cert onto my Heroku dyno.
You are correct - except it's not on your Heroku dyno, it's on your Heroku app endpoint. There's a good read here: https://serverfault.com/questions/68753/does-each-server-behind-a-load-balancer-need-their-own-ssl-certificate
If you do your load balancing on the TCP or IP layer (OSI layer 4/3,
a.k.a L4, L3), then yes, all HTTP servers will need to have the SSL
certificate installed.
If you load balance on the HTTPS layer (L7), then you'd commonly
install the certificate on the load balancer alone, and use plain
un-encrypted HTTP over the local network between the load balancer and
the webservers (for best performance on the web servers).
So you should install your SSL certificate to your Heroku endpoint and let Heroku handle the rest.
Question is, how does a client go about getting an SSL'ed connection;
do I need to get a multidomain cert and start adding domains to it as
I get clients, am i supposed to install their cert onto Heroku (I
believe I can only install 1 so thats a no go) or is it supposed to
live on Cloudflare somewhere?
If you're referring to adding servers to your service from heroku, all you need to do is increase the number of web-dynos. Heroku will handle the load balancing in between these dynos. Your SSL certificate should be resolved in the load balancer so your dynos will be serving requests for the same endpoint. You shouldn't need another SSL certificate for the endpoint you've defined - as long as you're serving traffic from multiple dynos attached to it.
I am trying to use Azure Traffic Manager to load balance traffic between a website hosted on an Azure VM in 2 different regions (Europe and US).
The Azure Traffic Manager is setup happily with the DNS name mywebsite.trafficmanager.net
I have 2 end points setup with dns names mywebsite-uk.uksouth.cloudapp.azure.com and mywebsite-us.westus.cloudapp.azure.com
In order to setup a vanity domain I have a CNAME record pointing to
www.mywebsite.trafficmanager.net
When I go to http://mywebsite.trafficmanager.net or www.mydomain.com I get correctly routed to the closest site.
Unfortunately I am struggling when I try to get HTTPS / SSL working. I am attempting to use Let's Encrypt via the Certify SSL Certificate Management tool to issue an SSL certificate to each of the servers however I am getting the following error:
Validation of the required challengers did not complete successfully. Please ensure all domains to be referenced in the Certificate can be used to access this site without redirection.
I have created bindings in IIS for both mywebsite-uk.mydomain.com and www.mydomain.com, and an A record for mywebsite-uk to the ip of the web server and whenever I request a certificate that includes www.mydomain.com I get the error.
Has anyone got an experience with this type of setup? and more importantly any advice on what I am doing wrong? Would I be better biting the bullet and getting a paid for SSL certificate?
Many thanks in advance,
We're running a lot of applications in Kubernetes and handle TLS termination inside a pod with HAProxy and a certificate generated with LetsEncrypt.
This works really well for traffic coming from outside the Kubernetes cluster because the requests use the domain name as specified in the certificate.
However for internal communication using the service name - with a url like https:/// - the host part of the url no longer matches what's defined in the certificate, resulting in failure.
Is there any way to let Kubernetes' dns system resolve the full domain name to a specific service, so it doesn't get routed outside the cluster?
I can think of a couple of options that you could pursue:
You could have the requests that transit just the cluster run over http instead of https if you trust the security of your cluster network.
You could have your HAProxy instance serve a different certificate to internal requests using SNI. You would need a way to generate and distribute the internal certificates, but it would allow you to present the client a certificate that matches the Kubernetes service name.
Continue to resolve the FQDN and not worry about routing requests out and then back into the cluster. This actually isn't that different than the upcoming cross-cluster service discovery/federation feature being built into Kubernetes cluster federation.
There isn't really a way to inject/overwrite the external FQDN resolution to return the internal service IP.
I am using the Let's Encrypt IIS client from https://github.com/Lone-Coder/letsencrypt-win-simple to generate a certificate for a server. Since the certificate is only valid for three months, I want it to auto-renew.
But the server for which I need that auto-renewing certificate is only bound to https:||mysubdomain.mydomain.com:443 and smtp:||mysubdomain.mydomain.com:25.
Both http:||mysubdomain.mydomain.com:80 and ftp:||mysubdomain.mydomain.com:21 point to a different server.
As you may have guessed, the error that is now thrown during the process is "The ACME server was probably unable to reach http:||mysubdomain.mydomain.com:80/.well-known/acme-challenge/abcdefgh...xyz".
It is completely clear to me why, but I can't fix it, because http:||mysubdomain.mydomain.com has to point to the other server. If the ACME server would try https:||mysubdomain.mydomain.com:443/.well-known/acme-challenge/abcdefgh...xyz, but ignore any certificate issue, he would successfully find the challenge.
Is there anything I can do, any feature I have overlooked, that would help me to get automated renewal working?
There are multiple options:
http-01
Redirect http://example.com/.well-known/acme-challenge/* to https://example.com/.well-known/acme-challenge/*, Boulder will happily follow any such redirect and ignore the provided certificate. That's the most simple way if you have access to the other server and can configure that redirect. It's a permanent redirect that you don't have to adjust, it'll be just fine every three months.
The option to use HTTPS directly has been removed due to security issues with some popular server software that uses the first host defined if some other virtual host doesn't define any HTTP host, which might lead to wrong issuances in multi-user environments aka shared hosting.
tls-sni-01
If you want to use just port 443, you can use another challenge type called tls-sni-01. But I think there's no client for Windows available yet that supports that challenge type.
dns-01
If you have control over the DNS via a simple API, you could also use the DNS challenge, it's completely independent of the port you can use.