I wanted to secure my apps running in a private subnet with SSL. Albeit not necessary, it is very nice to have.

Because of my constant changes, I opted for a wildcard ssl certificate through my DNS provider Cloudflare by providing Nginx Proxy Manager the necessary API token.

I generated the wildcard certificate with port 80 of the server closed to the public internet, and expected it to fail. Since letsencrypt required me to run a web server listening at port 80 to complete the challenge, I though that a wildcard certificate would also require the same setup.

However, to my pleasant surprise, I was able to obtain the cert and use it for my proxied apps. I would like to know how this was accomplished without Lets Encrypt reaching my server through port 80 and completing the ACME challenge.

  • Turns out to be unrelated but I don't get why it can't run the challenge on port 443 via HTTPS and just don't check the existing certificate.
    – Joshua
    Commented Jul 5 at 14:44

2 Answers 2


The ACME protocol doesn't use the HTTP-01 challenge when issuing wildcard certificates, because this challenge only proves you control the host behind a single domain.

For wildcard certificates, you have to prove control over the DNS records with the DNS-01 challenge.


If this is only for your internal needs ("my apps running in a private subnet") then you can use mTLS (mutual TLS). You generate own CA certificate, then generate Client/Server certificates and sign with your CA. Then use your CA certificate to verify remote certificate on each side. And prepare wildcard certificates for your domains without problem, free and without need to replace them every 3 months like Let's encrypt certs.

  • 1
    I strongly recommend against this. Running your own public-key infrastructure properly(!) requires an enormous amount of knowledge and work. The CA should also be run on separate hardware, ideally a hardware security module. Yes, anybody can set up a toy CA with the OpenSSL CLI. But if the CA operations are unprotected, this can allow an attacker to compromise the traffic of all services. So, no, a private PKI definitely isn’t a convenient alternative to Let’s Encrypt.
    – Ja1024
    Commented Jul 5 at 7:07
  • 1
    There are also good reasons for keeping certificates short-lived: It avoids the problem of revocation (which is often broken), and it more or less forces people to automate their infrastructure instead of getting a certificate once and then letting it rot for years.
    – Ja1024
    Commented Jul 5 at 7:07
  • 2
    @Ja1024 All paid certificates are for 1 or 2 years. There are no such for 3 months. And if own CA is a "toy" then what is usage of free Let's encrypt certificate for real business? You can easily dedicate Raspberry Pi (for example) which only keeps CA / private key, not used for anything else and not connected to internet. Its purpose is to generate new certificates and sign them with CA - then export with USB drive. "enormous amount of knowledge"? I don't recommend to run public CA and sell certificates. Maybe you have to read what is mutual TLS and is it such complex thing.
    – i486
    Commented Jul 5 at 7:16
  • 2
    @i486 the problem isn't really that running a CA is inherently difficult. It's that if you configure your clients to trust your own CA and that CA gets compromised, the attacker can not only MITM your own servers but all TLS traffic you make on the internet (certificate pinning excluded). Then there's also the issue of managing certificate distribution and revocation mechanisms and so on.
    – JensV
    Commented Jul 5 at 8:12
  • 2
    @i486 "...then what is usage of free Let's encrypt certificate for real business?" - Normal?
    – marcelm
    Commented Jul 5 at 22:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .