Is it possible to use a Reverse Proxy Server on Apache as a gateway for obtaining LE certificates??
Most of our servers are internal and have no Internet access. I was thinking about Reverse Proxy Server that maybe could pass through the request from Certbot to LE.
Like this for example: certbot certonly -d my.domain.com --server: proxy.domain.com
The Let's Encrypt validation servers (on the internet) need to be able to make a direct request to http://my.domain.com, as it appears in public DNS, and to receive a response.
Whether you can make that happen with a reverse proxy is up to you, but at the end of the day, your site needs to be made accessible to the internet.
If that's not possible, look into using the DNS challenge instead.
That doesn't really answer my question but ok.
I'm not sure how else to interpret the question, sorry.
To get a certificate, two forms of internet accessibility are relevant:
http_proxy and https_proxy environment variables in Linux.my.domain.com over port 80. This is what my first response was trying to address. If you have an Apache reverse proxy in your DMZ which exposes your internal servers' webservers, that would work. As long as the reverse proxy was exposed to the internet.That sounds like a regular outbound/forward proxy.
But you also need consider the HTTP validation requests that will come from the Internet and must reach the FQDN trying to get a cert.
If your internal systems are truly disconnected from the Internet, then you may need to use DNS validation instead. But if they are so disconnected... how can any system reach them or then validate any public cert they may use?
[I think we would need more information on how things are contained/separated to better give advice]
We have like 8 VMs and each has a subdomain. Only 2 of them have access to the Internet (websites) and the rest are just internal web apps that shouldn't have Internet access. All of it behind a Fortigate.
I was trying to find an automated solution for all these certificates.
Internal Root CA is nice but we're not in domain so distributing it to 300+ terminals is giant pain in the ass.
DNS API is not available unfortunately.
I came across someone pointing to proxy as a solution or even DNS Alias.
If you can control the access via proxy, then that is a good place to start.
As it simplifies the requirements to just one system (the proxy).
But, since DNS authentication is not an option, the proxy will have to validate via HTTP (or HTTPS) authentication.
This means the Internet will have to reach the proxy via (at least) one of those two TCP ports.
I would suggest allowing port 80, handling the challenge requests there, and forwarding the rest to HTTPS.
In HTTPS you can block all that are unwanted - i.e. you can even block all and only allow those you do want in.
I would suggest a dedicated VM placed into a separate VLAN that only sees the FW would contain and control this nicely (and should pass any and all security audits).
I'm sure you can do with using an Apache reverse proxy but it seems to me like an awkward approach.
My advice would be to forget http validation altogether and use DNS validation. You can host your own acme-dns service (or check out Certify DNS certifydns | Certify The Web Docs) to handle DNS validation challenge responses. This technique uses a CNAME (in your real public DNS) for each host name pointing to a dynamic record hosted on the DNS validation service. This dynamic record is updated during renewal, leaving your own DNS untouched. All popular ACME clients support this technique. You create the CNAME once per hostname and renewals can be handled automatically forever after.
Some ACME clients also support surrogate domains for validation (e.g. you can CNAME _acme-challenge.app-01.yourdomain.com to a _acme-challenge.app-01.auth.yourdomain.com). That way you can have the public DNS hosting for auth.yourdomain.com on something public with a well supported API (like Cloudflare, also free), and just use it for domain validation.
Once you have a method for renewing all of your certificates you need a deployment method to copy the certificate to each destination and apply them (or pull the certificate and apply it). This can be done with scripting in most cases. Other techniques include storing your renewed cert in a vault (Hashicorp vault, Azure KeyVault etc) then the individual servers pull the latest cert on a regular basis (again, with a script).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.