We've been using a PositiveSSL Multi-Domain Cert for some years, and that's been working fine. Under that Cert, we have, for instance:
domain1:
mail.domain1.com
www.domain1.com
domain1.com
domain2:
mail.domain2.fr
www.domain2.fr
domain2.fr
etc., with a total of 5 different domains.
Now, since we're going to expand our domain base and that the current Cert is expiring, we're looking closely at Lets-Encrypt.
Before I get into this, however, I'd like to know a couple of things:
(1)- does every subdomain (mail. www., etc.) as well as their main respective domain have to be listed in the main certificate? I'm mainly asking that because (a) that was my original understanding, and (b) the verification stage with Lets-Encrypt will differ (preferred-challenges=dns instead of by default apache-based), which will lead me to add DNS records for each domain/subdomain.
(2)- if it is indeed needed (and if I have no choice but use preferred-challenges=dns, at the time of the next Cert renewal (i.e. < 90 days), should the DNS records still have to be present? I'm asking this because last time I left the DNS records after creation, the mail server couldn't be reached anymore after the DNS propagation time. I'm pretty sure that it was because of my bad setup, but it's a risk I prefer to avoid taking.
(3)- if I'm missing here of you have a better advice to give me, let me know.
At https://websocket.email I am using the Subject Alternative Name (SAN) mechanism to handle api.websocket.email etc. I did not have to configure DNS records and used http challenges. The exact way you would do this depends on your acme client. Mine had the option listed under a config section "alternative names".
Edit: To clarify, I needed DNS records to point to my subdomains all to the same server, I am using this acme client - https://man.openbsd.org/acme-client.conf.5 and set the alternative names option. When getting my certificates I could see in my http logs, lets-encrypt fetching a single challenge file per domain to prove I own it.
In case someone has a similar issue or plan, this is what I've learned during this process:
Every domain name that the certificate will be used for has to be included. Let’s Encrypt will validate each of the domain names in the certificate.
If using DNS-01 validation, all of them will require DNS records to be added. With that, records will be required to re-validate the domains every 90 days (or whatever time frame you choose). This will require adding a new TXT record each time. Leaving the old TXT records from a previous validation will not work, the value changes each time.
There are also HTTP-01 and TLS-SNI-01 challenge types. If you already have an Apache instance running I recommend using HTTP-01.
If you don’t have a webserver on the machine that runs mail.domain1.com you can still use HTTP-01. Certbot has a feature called “standalone” mode where it can start up a small purpose built webserver to answer HTTP-01 challenges to provision a certificate.
To use HTTP or TLS-SNI validation on a non-web server, you would run something like: certbot certonly --standalone -d mail.example.com. You still need to have port 80 or 443 open in your firewall to use this method, but you need no server running on those ports. If you only want to open one port you can specify the challenge type explicitly, e.g. --preferred-challenges http to use port 80 or --preferred-challenges tls-sni to use port 443.
Related
Looking at the instructions here: https://certbot.eff.org/lets-encrypt/ubuntubionic-haproxy
I'm in a situation where I have 2 HaProxy instances, each in a docker container, on different machines. The domain names are the same. This is done for redundancy purposes.
Googling "multiple letsencrypt" or "multiple certbot" just leads to solutions for creating certificates for many domains at the same time.
This is good for subdomains, but it doesn't explain what I'm expected to do if I have more than 1 server running haproxy.
Run certbot on 1 server only, then copy the file over? If so, what about renewing the certificate? Can it no longer be automated?
Also, because of urls, certain subdomains will go to one server or the other. But both must be able to serve all the urls.
Or does this situation call for a different approach entirely? Should I use the manual mode, generate the certificates, and then update them manually?
Thanks for any help.
Eventually found a solution: you can start certbot with a custom port, --http-01-port as you can read here: https://eff-certbot.readthedocs.io/en/stable/using.html.
If all your haproxys detect the incoming challenge URL "/.well-known/acme-challenge", you can have them redirect to that host/port combo. So all challenges end up at the certbot.
Then find a way to move the certificate around.
I would suggest you to go with getssl which is a "simple" Bash script taking care to :
deploy the challenge file to all the required nodes, to the right place, and even reloading the remote node web server
deploy/copy the generated SSL certificate files to remote nodes too
It can use SSH, SFTP or FTPS to transfer files. You then can add a cron job to execute getssl everyday and it will renew the certificate and distribute it when done (a config allows you to tell when to renew the certificate).
Is it possible to give a application load balancer on AWS a SSL certificate, allowing allowing only HTTPS connections, if I don't want to use a custom domain?
Currently developing some internal dashboard applications, so have no need/want for a domain name attached to them.
I can only dig up info and tutorials of creating to a certificate in Cloudformation, when wanting to add a domain forwarding to the LB.
The SSL certificate has to have a valid DNS name associated with it in order to work. You need to request a certificate via ACM and then attach that to the ELB. You can configure the ELB to only have an HTTPS listener to force secure communication.
Probably not.
It's not generally kosher to issue an SSL certificate to an IP address, and since all *.compute.amazonaws.com style DNS names are floating and could be reassigned at any moment, they damn well won't issue one for them either. (Same stands for Let's Encrypt, by the way: you have to have a DNS name not issued by a provider.)
Just give your internal service a DNS name, be it something like mydashboard.internal.mycompany.com or whatever; it'll be easier to access, too.
All the documentation for Service Fabric mentions that for a production cluster you should use an X509 certificate from a trusted CA with the common name of the cluster address. The problem is I can't find any documentation on the process of obtaining the certificate. As far as I can tell for creating a certificate you need to prove you are who you say you are and to do so you either need to own the domain or expose some sort of file on the specified address.
The problem is that the url of the cluster is on a domain owned by Microsoft and my cluster is not exposed to the outside world as a website. Am I missing something? Do I have to create a web service and expose it in order to just create a certificate?
You can use any a free solution like Letsencrypt, for this it's not required to own the domain (specifically; control the DNS records). They also provide the option to respond to a HTTP based challenge, as proof of control.
To kick off the process, the agent asks the Let’s Encrypt CA what it
needs to do in order to prove that it controls example.com. The Let’s
Encrypt CA will look at the domain name being requested and issue one
or more sets of challenges. These are different ways that the agent
can prove control of the domain. For example, the CA might give the
agent a choice of either: Provisioning a DNS record under example.com,
or Provisioning an HTTP resource under a well-known URI on
https://example.com/
An easy way to get started with Letsencrypt is by using CertBot.
This needs to run on the domain, so it can respond to the HTTP challenge, which results in the issuing of a certificate for your specific cluster endpoint.
Maybe this sample project helps.
I have a gadget[*] that connects to the user's WiFi network and responds to commands over a simple REST interface. The user uses a web app to control this gadget. The web app is currently served over http and the app's javascript does AJAX calls to the gadget's local IP address to control it. This scheme works well and I have no issues with it.
[*] By "gadget" I mean an actual, physical IoT device that the user buys and installs within their home, and configures to connect to their home WiFi network
Now, I want to serve this web app over https. I have no issue setting up https on the hosting side. The problem is, now the browser blocks access to the gadget (since the gadget's REST API is over http and not https).
The obvious solution is to have the gadget serve it's REST API over https. But how? It has a local IP address and no one will issue a certificate for it. (Even if they did, I'd have to buy a boatload of certificates for each possible local IP address.) I could round-trip via the cloud (by adding additional logic on my server side to accept commands from the web app and forward it to the gadget over another connection), but this will increase latencies.
Is there a way around this problem? One possibility that I have in mind is to:
Get a wildcard certificate (say, *.mydomain.com)
Run my own DNS that maps sub-domains to a local IP address following a pattern (For example, 192-168-1-123.mydomain.com would map to 192.168.1.123)
Use the wild-card certificate in all the gadgets
My web app could then make AJAX calls to https://192-168-1-123.mydomain.com instead of http://192.168.1.123 and latencies would remain unaffected aside from the initial DNS lookup
Would this work? It's an expensive experiment to try out (wildcard certificates cost ~$200) and running a DNS server seems like a lot of work. Plus I find myself under-qualified to think through the security implications.
Perhaps there's already a service out there that solves this problem?
While this is a pretty old question, it is still nothing that you find out-of-the-box solutions for today.
Just as #Jaffa-the-cake posted in a comment, you can lean on how Plex did it, which Filippo Valsorda explained in his blog:
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
This is very similar to what you proposed yourself. You don't even need a wildcard certificate, but you can generate certificates on-the-fly using Let's Encrypt. (You can still use wildcard certificates, if you want, which Let's Encrypt supports now, too.)
Just yesterday I did a manual proof-of-concept for that workflow, that can be automated with the following steps:
Write a Web Service that can create DNS entries for individual devices dynamically and generate matching certificates via Let's Encrypt - this is pretty easy using certbot and e.g. Google Cloud DNS. I guess Azure, AWS and others have similar offerings, too. When you use certbot's DNS plugins, you don't even need to have an actual web server running on port 80/443.
On you local device, contact that Web Service to generate a unique DNS entry (e.g. ..yourdns.com) and certificate for that domain
Use that certificate in your local HTTPS server
Browse to that domain instead of your local IP
Now you will have a HTTPS connection to your local server, using a local IP, but a publicly resolved DNS entry.
The downside is that this does not work offline from arbitrary clients. And you need to think of a good security concept to create trust between the client that requests a DNS and certificate, and your web service that will generate those.
BTW, do you mind sharing what kind of gadget it is that you are building?
If all you want is to access the device APIs through the web browser, A Simple solution would be to proxy all the requests to the device through your web server.this was even self signed certs for the devices wont be a problem. Only problem though is that the server would have to be on the same network as your devices.
If you are not on the same network, you can write a simple browser plugin (chrome) to send the api request to IoT device. but then the dependency on the app/plugin will be clumsy.
I can't work out a definitive answer on this, but from searching I find two links which seem to indicate to me that a server (in this case it's MS Exchange as per the links) can have different certificates in place for https than for secure smtp/TLS.
http://technet.microsoft.com/en-GB/library/bb851505(v=exchg.80).aspx
https://www.sslshopper.com/article-how-to-use-ssl-certificates-with-exchange-2007.html
I have an issue which no-one has been able to help with here and this question is a follow on, in that I am coming to the suspicion that my first problem is that my machine trusts the https certificate, but not the one being used for smtp/TLS. But what I'm asking now, is that even possible?
Going through the diagnostic steps here shows me that the certificates in use when I access my mail server's web interface through https are fully trusted. However when I look at the debug of my c# process it is stating a completely different certificate issued by one of our servers to it's self (the server on which exchange is installed).
So... any one know if it's possible that I am thinking along the right lines... is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Is it possible that when I do an https connection I get one certificate and when I use the .net SMTP client I get a completely different certificate (from exactly the same address, but I assume a different port)?
Yes, you can have a different certificate for each listening socket on the machine, that is SMTP and HTTPS can use different certificates. On a machine with multiple hostnames you could even have multiple different certificates on a single socket, which get distinguished by the hostname (using SNI).