Automatically certify local development servers along with remote production servers

Many website developers run local development servers, whether Apache, Caddy, node.js-based, or hundreds more. It can be inconvenient to develop using HTTP insecurely, since security features cannot be fully tested or correctly configured for uploading files to a corresponding remote production website.

I have come up with my own method for using HTTPS in my local development, which I describe below. But my suggestion to Let’s Encrypt would be to include support for local development servers (either by Acme-certbot or some other protocol).

I’m not including a specific design, but I would hope that local development servers could be supplied automatically with certificates compatible with or identical to certificates already installed on remote production websites.

I use cPanel for my production websites. What I’ve done is use cPanel or WHM to add a subdomain “” for existing production website “”. There is no need for a corresponding remote directory, or a need for corresponding DNS entries. This subdomain is only created so it will be part of the Let’s Encrypt certificate on the remote production server.

Then, in my local development server, I enable HTTPS for a website using certificate files copied from the corresponding production website. When I want to address my local development server in a URL, I use the address “…” (the “https://” can be omitted when the website uses HTTPS automatically). Note that the local HOSTS file must have an entry “” so the local server will be used for this subdomain.

A big advantage of this method is that browser windows can be open simultaneously to local and remote versions of the same website without further changes to the HOSTS file and without ambiguity in the domain name.

The only problem with this approach is that the local certificates expire and must then be refreshed manually by copying from the remote production server.

So, my suggestion is that Let’s Encrypt include an optional automatic procedure for making sure that local development servers have current copies of remote certificates, or perhaps automatic certificates of its own. This would further encourage and support a secure Web.

I get what you are saying/asking, but it may require breaking CAB rules to do what you want and HOW you want it.

In the interim, I would suggest using wildcard certs and having your internal/local systems get their own certs via DNS authentication - provided that your “test” systems have access outbound to your authoritative DNS servers.

You do realize that you can use self signed certificates for, do you?

We seem to have some communications problems.

I wonder if you might give some details related to your reply, most of which I could not understand. Here are my specific questions:

  1. What are CAB rules? I have searched the Web and can find nothing relevant.

  2. Why can’t I do what I want? It has been working for me successfully for years now. I’m just asking Let’s Encrypt to cover development as well as production systems so developers can take advantage of HTTPS during their development work.

  3. I know what wildcard certificates are, but I don’t think that cPanel issues them through Let’s Encrypt or otherwise. Assuming I am wrong, in what way would wildcard certificates be of help? Each of my websites has its own domain name, so it needs its own certificate. Or is it possible to have one certificate that covers all the domain names that are being served? That doesn’t sound secure to me.

  4. How does one get a certificate via DNS authentication? Currently, I connect to cPanel and navigate to the domain certificates, display them, and copy them to the clipboard. I understand DNS and its zone records, but am not sure what you mean by authentication or getting the certificate.

  5. Yes, I would expect local development servers to have WAN access to the Internet, so they can get to the auth zone DNS records. I’m unclear on how that would help.

Yes. I can create self-signed certificates, and even my own certificate authority. My suggestion stands, for best results in every testing and development scenario, even those that must examine or modify TLS handshaking or other internals.

CAB is short for CA/Browser forum:

They decide on the Baseline Requirements (BRs) which any public CA has to follow if they want to be included in browsers. You can find the BRs here:


And if Let’s Encrypt starts issuing certificates for local domains, their root certificates (and possibly the root of our cross sign by Identrust?) could (or probably most certainly would) be removed from root certificate stores! I.e., no browser or operating system would trust Let’s Encrypt certificates any longer.

1 Like

I think he’s talking about some sort of split dns configuration. Having and resolve to the external webserver, acquire a certificate valid for both names there, then using that cert locally with a hosts file entry for development.

This wouldn’t break any CA/B rules, and a simple script to copy the certificate to the local development machine should do the job.

Yes, that is pretty much what I actually wrote. Browsers don’t have to add any new CAs to their bundle.

1 Like

I don’t see how this is a feature request then. I think all you’d need to do is configure a deploy hook with certbot to copy it wherever you need it.

How is that NOT an available option today?
He would still have to copy the cert from the outside system to the inside system(s).

With DNS auth, the inside system(s) can get its' own cert.

1 Like

I didn’t say that Let’s Encrypt should issue separate certificates for local domains. That would be too complex and invasive. Just that the update of a certificate should include the local domain through some script that would run on the local computer.

I don’t have access to certbot. As I wrote, I use cPanel on the remote server. cPanel doesn’t support local development servers, nor should it.

The thing is, actually obtaining, deploying and moving certificates around isn’t in the scope of what Let’s Encrypt does. Let’s Encrypt provides an ACME API, it’s up to the ACME client to do the rest.

If your ACME client doesn’t have the features you need you should switch to a different one or submit a request with the developers of it.

Or as rg305 mentioned, you could just run a client on your local development system and obtain another cert with the DNS-01 challenge


Okay, I will post this at a Certbot forum, since that is the most popular Acme script, if I don’t find another solution that works for everyone.

Exactly what do you mean by “run a client on your local development system and obtain another cert with the DNS-01 challenge”? I have no idea how to do that or what it really means.

There are several ways to authenticate.
There are many different clients.
Here is one example:

But I don’t want to deploy a Let’s Encrypt certificate on a local development server, at least not directly created and renewed through Certbot.

I found, which suggests creating “”. This corresponds to my “” which I invented myself. The rest of the steps seem to require Centos, and get vague, but my local server is under Windows Home, which is why I thought that Let’s Encrypt should address the issue of local development server certificates itself. Then Let’s Encrypt (or Cerbot?) would provide local scripts for all OSes to update local certificates. That was the intention of my post.

Two different people seemed to suggest that there is a way to use the DNS records from the local server to obtain the private key and certificate. I’ve asked both people how this is done. Can it really be done from a local script? I have no idea how. ADDED: I am VERY skeptical that DNS records would ever contain certificates, since the entire DNS system is insecure. So there.

Certificates are certainly never put in DNS. The 1000-foot view of the DNS-01 method of the ACME protocol is that your ACME client contacts the server, say Let’s Encrypt, asks for a random key, and instead of copying it to your web root it creates a new DNS entry with it. LE will then try to verify it, and if it sees it, send your certificate back to the client. It’s a one-time key that expires quickly, so it doesn’t matter if anyone else sees it after that.

Conceptually, the protocol works just like HTTP-01, except that it tests your DNS instead of you web server, so that you don’t need any ports opened up.

DNS APIs of providers being less than entirely standard, it’s trickier, which is why the documentation section above has so many plugins you can choose from, including one where you just manually set it.