Using certificate for testing purposes

Hi, I have acquired an SSL certificate for my domain, but I want to use it in unusual way. Let me describe what common problem I want to solve.

I am a web developer and my web-application recently migrated to https. I had to adapt it to https and check locally whether it works correctly, but I don’t have access to our production SSL certificate. So I went a standard way: generated a self-signed certificate for ‘local-app.com’, applied it to local web-application, added entry to file etc/hosts ‘127.0.0.1 local-app.com’ and then hardly found a way how to force browsers trust it.

You see the problem, my team members along with thousands of developers has real pain when trying to compel browsers to trust self-signed SSL certificate. But I have a much better solution for this task.

I have registered a domain name
https://my-local-site.com/

And I want to share its SSL certificate (with private key) with my colleagues and everyone who need to test https locally. If a developer needs full-fledged https on localhost or local server he will download and apply certificate, just add ‘127.0.0.1 my-local-site.com’ to etc/hosts and that’s all.

It will save considerable time for thousands of developers all over the world, that fact will make me pleased with myself. And no any negative influence on Let’s Encrypt’s mission or SSL infrastructure. Site itself will be static, no any confidential traffic.

I am posting this to let you know about my idea beforehand, so you can see that the idea makes sense.

I ask you just not to revoke certificate. Moreover it will advertise you among thousands of potential users.
Please let me know if you object against my idea.

Looking forward for your reply!

@baur, if you check https://letsencrypt.org/docs/revoking/, you’ll see that it is possible to revoke Let’s Encrypt certificate by proving that you’re in control of its private key (“If you did not originally issue the certificate, but you have a copy of the corresponding private key, you can revoke by using that private key to sign the revocation request.”).

Also, publishing private key is forbidden by subscriber agreement:

You warrant to ISRG and the public-at-large that You have taken, and You agree that at all times You will take, all appropriate, reasonable, and necessary steps to maintain control of, secure, properly protectand keep secret and confidential the Private Keycorresponding to the Public Key in Your Certificate (and any associated activation data or device, e.g. password or token).

I believe that this is due to CA/Browser Forum Baseline Requirements, which state that:

4.9.1.1. Reasons for Revoking a Subscriber Certificate
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
(…)
3. The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;

and

6.1.2. Private Key Delivery to Subscriber
(…)
If the CA or any of its designated RAs become aware that a Subscriber’s Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

Not keeping private key private (even intentionally) is considered by CAs as a key compromise - you may check discussion at Private key corresponding to public key in trusted Cisco certificate embedded in executable.

Let’s Encrypt is bound by CA/Browser Forum Baseline Requirements - they cannot grant you an exception, or they will face risk of removal from root trust stores.

I believe that localhost.daplie.me was based on the same principle and their certificate got revoked.

2 Likes

interesting idea

i would suggest another approach which is to run your own CA and let people obtain a localhost cert and install the root

i usually suggest developers buy an xyz version of their domain $2 and setup DNS verification

Andrei

Firefox shows a warning on “self signed” certificates and lets the user import it. The same procedure (import certificate in local trust store) should be supported by any browser and operation system.

Certificates from Let’s Encrypt are not suitable for local development, in my opinion. Besides I don’t see any reason why a web-application should behave different when called via http or https. If the protocol is not hard coded somewhere, no problem should arise.

@mkwm, thank you for fast and detailed answer!

If we take a look at definition at page 9 CA/Browser Forum Baseline Requirements

Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an unauthorized person may discover its value. A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the specific method used to generate the Private Key was flawed.

We can see that in order to avoid compromise I just have to authorize every person before share the key.
For example, if I give the key to my colleague, he or she is an authorized person.
And I can authorize more people to be given a key.
Site will demand an agreement on authorization contract between me and that person.
In this case there wouldn’t be an exception and everyone will benefit.

You can just google:
'make [browser-name] accept self signed certificate on [OS name]'
and see that methods are not so obvious and they even evolve along with browsers.

Real SSL certificates are sometimes better than fake ones.
One of reasons is that not only browsers connect over the https.

Web frameworks distingushes whether client connection is secured or not.
For example, secure cookies are sent only over https.

Even if Let’s Encrypt didn’t revoke your certificate, anyone could, as @mkwm noted above:

Since you want to share the private key with anyone, anyone will be able to revoke the certificate.

I would suggest something a bit different - you can “provide” your users with individual subdomains of my-local-site.com and generate separate private keys and certificates for each of these domains.

This could work like that:

  • User creates new project on your website (for example my-test-project)
  • my-test-project.my-local-site.com gets assigned to that user (note: you don’t provide user with DNS service, only “reserve” such domain for their use)
  • Private key and CSR for my-test-project.my-local-site.com is generated on their behalf (this could be even done in-browser, using JavaScript)
  • CSR gets sent to Let’s Encrypt to be signed (with DNS-01 domain control validation method)
  • Private key and signed certificate is returned to user with instruction that they should put 127.0.0.1 my-test-project.my-local-site.com in their /etc/hosts file
1 Like

@mkwm Excellent idea! I really like it!
But what about limitations on subdomain certificate issuing?
What if 200 people will register 200 unique subdomains within 24 hours and claim 200 private keys?
What would be a limit from LetsEncrypt side?

You would probably be able to get rate limit adjustment (https://letsencrypt.org/docs/rate-limits/, “Overrides”).

I guess if you would provide such service to general public, it may be a good idea to get my-local-site.com included in Public Suffix List, just like people behind localhost.daplie.me did. If someone happens to use two “projects” at my-local-site.com simultaneously, they would be considered different web origins and won’t be able to mess up with cookies at your domain level. If your domain ges included in PSL, you won’t need rate limit adjustment (as Let’s Encrypt uses PSL to calculate domain control boundaries).

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.