I just wanted some people’s input about a solution to a problem I have.
How bad is it if I decide to ship a LE certificate and key to a web server which will only be deployed and accessed locally.
The Hostname will satisfy the DNS-01 challenge and will point to 127.0.0.1.
Of course it means the Certificate and the Key being widely distributed and renewed every time but shipping and updating is not a problem.
This is to avoid the famous MIXED CONTENT error because a URL at https://blih.mycompany.com would need to have access to say https://localhost.mycompany.com which is 127.0.0.1.
To my opinion since the Key will be widely distributed but could only decrypt localhost to localhost traffic which was in HTTP anyway, it’s fine to implement.
@tehmoon, I didn’t understand whether you meant to do this for an application that you’ll distribute to the public, or just “widely distributed” within an organization. If you publicly distribute the private key you will be in violation of the Let’s Encrypt subscriber agreement, and anyone can cause the certificate to be revoked by reporting this to the CA (or they can even revoke the certificate themselves using that private key).
I think there have been other threads about people wanting to use localhost but in order to examine what might be possible, we’d need to know a little more about the structure of this application. Is it something that you’re distributing to the public somehow? Are you controlling the entire platform and environment, or just running a local web service of some kind on people’s machines? Something else?
Yes the application will be publicly released for everyone who wants to download and use our product.
The application will run a web server that listens to 127.0.0.1:port and only authorize HTTP requests from http(s)://localhost:port. Except for one URL /ping which is used to check from an external website if the local web server is alive -- by using some simple javascript xhr local calls.
I am controlling the entire platform and environment and plan IF possible to have a new certificate during our NightlyBuild so it stays valid.
For now, I'm generating LE certificate using an Account Key which is store securely somewhere. Will that make it harder to revoke the Key?
I'm going to look deeper into the docs and the forum see if I can find some insights.
Unfortunately there is only one reply in that thread, but maybe it will have some ideas for you.
Distributing the private key corresponding to the subject public key is forbidden by the Let's Encrypt subscriber agreement, even if you don't distribute the account key. The private key corresponding to the subject key can also be used by itself to perform revocation. While it's not clear that someone would succeed in revoking your certificate every time if you made a new one every day, having a routine, automated violation of your subscriber agreement is not a good idea to rely on.
I think it would be interesting to hear what browser vendors think about HTTPS for localhost, and maybe we could try to get ahold of some of them and get them to comment here.
If the local web server will only be accessed by your application, you might be able to get by with a self-signed certificate that your application trusts, bypassing the need for a public CA.
That’s what we are currently evaluating. We are thinking about generating a 3650 days certificate and have it trusted by installing it in the system for a specific DNS name which will be 127.0.0.1. The key being for the certificate to be valid from ANY major browsers.
If you’re going to do that, be sure to make sure it’s stated in the documentation. For more security, if you do this you could try to generate a unique self-signed certificate on each install, which will prevent messes like Lenovo (superfish) and Dell (eDellRoot) got themselves into. Those were slightly different in what they did, but having an identical cert with the exact same private key was a major issue that made things worse.
From the other thread, you can and should also use name constraints as @pfg mentioned, so that the cert doesn't allow intercepting connections to other sites. This is a good piece of proof that your application isn't spyware.
I'll try to make contact with people I know at Mozilla and Google to see whether they have any recommendations in this area.
Actually we wanted to have 127.0.0.1 as the Common Name. But we saw it’s not really valid. So for the PoC I ended up doing http://apetec.com/support/generatesan-csr.htm which I only authorize 127.0.0.1 as valid IP address so people could safely browse https://127.0.0.1:port.
@tehmoon, that’s valid from the X509 technology point of view but no publicly-trusted CA is allowed to give you a cert for that CN, so using your own CA is safer.
By the way, an alternative to adding your own root might be adding your own self-signed leaf certificate for 127.0.0.1, which would avoid the need to name-constrain a root. You could test whether different browsers can understand this. One difficulty is that importing a leaf certificate may be a more browser-specific task than importing a root (!).
So the goal would be to generate a certificate and sign it with a certificate that has been signed by a trusted certificate already installed?
Like this scheme: leaf -> my own valid one -> Trusted CA?
Did I get that right?
#EDIT
I don’t think what I just said made sense and actually works.
What I did to avoid the name constraint problem is having the common name set to: My Company Ltd and the actual IP address is in the subjectAlternateName.
So we ended up having our local application acting like a TLS proxy to one of our backend which has a LetsEncrypt certificate.
The browser queries https://mylocalhost.blih.com which points to 127.0.0.1 and gets the certificate from the remote backend.
Works like a charm!
In this architecture, I don't understand why you wouldn't just connect to https://service.blih.com/ and directly provide the service. Or do you need to do computation and access local files?
Your solution is clever and I hope it works OK with scalability and reliability.
Also, you should make sure that you cryptographically authenticate the remote backend somehow, and that you're not downloading the shared TLS private key for mylocalhost.blih.com to each user's machine.
The Key stays on the server and is never shared with anyone.
The main point was to avoid the mixed content error when we wanted to see if our application was installed on the user’s computer from a HTTPS website.
Now we can call a URL that points to 127.0.0.1 from a HTTPS external website but the call is a TLS proxy to a server WE control. If the call is successful, the local application is installed.
And we can safely redirect the user to the local application – which is going to be http://127.0.0.1:port.
Thank you so much for your input as well as @motoko.
But how? If you are outside the LAN then no router is going to let you look at a client's internals through 127.0.0.1, or is that sentence not quite precise in the "we" being "the client would see".
Initially you stated
and then this would concern me
as I can't see how you cannot be shipping the private key for the web server listening on 127.0.0.1 unless you are shipping one key per application. I'm guessing the architecture, your application "inside a company" has a web server built in but requests outside the company for some assets which are served through https, so as this application is running locally you want to make sure that it is serving local assets through https as well. So how is this application accessed? by someone in the company going to https://software.insidecompany.com because if that's the case then the cert should be issued to https://software.insidecompany.com as any web page displayed from that domain pointing to 127.0.0.1 is going to look on the user's computer, and in that case then the only way the application is going to work is on a one certificate per user being shipped with the web server and private key. It might be working on your computer as your server has the private key but replicating and renewal for every single user running their own unique web server does not seem like the most efficient design.