Has any thought been put into providing a method verifying addresses for Private Intranet Sites?
Example
You if you own the domain example.com and have the subdomain intranet.example.com but it’s only accessible to clients on the company’s internal network Lets Encrypt wont be able to connect to the site to verify ownership.
Has anyone thought of any easy workarounds for this?
This suggestion seems interesting for this:
We have previously suggested temporary TCP port forwarding or obtaining the cert on one (temporarily public) machine and then copying it and the private key onto a non-publicly-visible machine.
I think the most secure approach is to generate a private key and CSR on the internal machine and then use manual mode on a temporarily publicly-visible machine which has the public DNS record pointed at it. I realize this isn’t very convenient and we could probably have more tools to help automate the process.
The issue is if you don’t have a split DNS, or have no feasible way to make the server (as exactly named) publicly accessible.
If you have a split dns to where you could serve up a different dns to the outside world, sure - it’s super easy to use any of the alternatives.
However, that doesn’t address the additional case where you can’t easily do forwards or alter what’s running on the box OTHER than the cert. Take the example of a vendor locked down appliance/router/gateway/etc. sitting on a public IP with a defined name. None of the workarounds really work for that case. You can’t necessarily add forwardings, or alter content, and since it is actually on an accessible IP, you can’t take it offline to serve up something else on the standard ports.
Obviously, full DNS based validation is the end-state easiest answer to this. My suggestion above (supporting a srv record) was just one to add a minimal amount of code which would add the ability to influence/tune the simple-http validation, without having to fully implement the DNS support.
@nneul, that seems like a good explanation of the problem. I don’t expect this verification method to be available before Let’s Encrypt’s general availability.
I have absolutely same problem intranet.example.com published only in local DNS, nothing in publich DNS so I can’t create certificated at now, because didn’t exists record in public DNS
if would exists any solution, it would be great
@schoen Any idea where this (or other DNS based validation methods) might site on the priorities list/timetable now that you’re in public beta? I have 100+ internal devices that I would jump at the chance to use LE for, but can’t currently due to the validation constraints and the way our DNS is set up.
I don’t wanna sound like I’m against it, but if that intranet is anyways only reachable behind company firewalls from the inside of the company network, I think it is an options to throw in an own CA just for that purpose. Setting up an internal CA for that is no problem in neither in the Windows nor in the *nix world.
And at least if all Windows machines are in a windows domain it is even piece of a cake to distribute the CA into the trusted CA certificate store from what I know.
We’re doing something similiar that for signing our internal windows applications at work.
Yeah, and we’ve done that to a limited degree - but there are quite a few people, with locked down windows boxes, and lack of support/interaction with domain admins/etc.
Being able to fully automated it, with known trusted certs, using the easy capabilities provided by LE would be ideal.
There’s also quite a few cases where the internal audience is large, even though the target system with the cert isn’t accessible to the public internet. In those cases, changing cert trust internally isn’t ideal.
Setting up an internal CA for that is no problem
If that would really be the case, the question would not have been brought up in the first place. In fact it's a huge problem, especially for small or mid-range companies. Besides of typical problems arising by simple PKI operations (key storage, RA, etc.), the CA deployment is getting more complicated since BYOD and BYOB (bring your own browser) is more the rule than an exception. Especially smaller companies do not have a homogeneous IT infrastructure which allows simply deploying a CA certificate, which is then accepted in all browsers installed on the user's device... Also in bigger companies it's often allowed to use private mobile devices as smartphones and tables, which are not subject to companies configuration management systems...
@nneul I really like the idea of SRV RRs (or even TXT RRs) being validated instead of A records. Since the identity validation is never a "main intention" of owning the domain, the A RR is not the best choice anyway (but of cause the most usable one).
Ok, I must confess, I didn’t took BYOD into account. That indeed can be a problem.
Anyways, I’m not against DNS based domain ownership verification, I indeed support it for other reasons. I only wanted to offer a possible solution. 
dns validation is now in the production servers and supported with several third party clients such as https://github.com/lukas2511/letsencrypt.sh and lego. Production server has a known bug though with certain DNS providers that is in process of being fixed upstream.
My use case is a server behind NAT. I had successfully generated and installed a certificate for https://jimmy.macewan.nz.
Unfortunately I can’t test this from within my private IP network. After reading this thread I set up local.macewan.nz to resolve to 192.168.1.71 (certbot was at least explicit about not allowing IP addresses.)
I then tried to generate a new certificate using the SAN capability (by using what appears to be the otherwise undocumented mechanism of multiple -d example.com type domains) but CertBot repeatedly complained that local.macewan.nz did not resolve. It did, but it appears that resolving to a private IP is the same thing as not resolving. It would be nice if the error was a little more helpful, if this is the case.
So I changed the A RR for local.macewan.nz to point to the same public IP address as jimmy.macewan.nz.
certbot certonly --webroot --webroot-path /path/obfuscated -d jimmy.macewan.nz -d local.macewan.nz
That worked, and a certificate was generated.
I then changed local.macewan.nz’s A RR back to resolve to 192.168.1.71
And so now I can make uninterrupted access to jimmy locally using local.macewan.nz. Way too much effort, but I wanted to know it could be done.
This will suffice for the next 90 days until I have to renew the certificate… and that’s something I’m not looking forward to. Taking the server down for renewal is bad enough, but messing with the DNS is worse.
Could LE be a bit more tolerant of FQDN that resolve to private IP addresses, at least in the SAN?
In short, no - it needs to verify ownership. Otherwise you could say that paypal.com is on your local network and a SAN, and then obtain a cert for paypal 
Is there any reason why you don't just say locally ( within your network) that jimmy.macewan.nz is on 192.168.1.71 and then you just use jimmy.macewan.nz as normal and it would just work ? rather than you needing to use local.macewan.nz to reach it internally - or am I missing something
What don’t you just use DNS based validation? Then it works just fine with internal or external hosts.
I don't think Paypal.com in any circumstance would resolve to 192.168.1.71 (or anything else but what it does resolve to) so if I put paypal.com in the SAN section claiming ownership the server should reject it, I agree.
Perhaps there is a longer explanation.
I've probably explained poorly, this isn't an area of great expertise for me.
I don't run, nor want to, split DNS that gives inconsistent results in-house (flat actually) such that jimmy.macewan.nz resolves to something different on the local network.
https:/./192.168.1.71 complains that the name isn't valid, certbot -d 192.168.1.71 complains. I'm trying to find a simple, non-complaining solution.
Because it's not available from certbot?
I would certainly very much appreciate being able to use DNS validation. If available I don't know why anyone with DNS control would use anything else, but would I be wise to mix clients at this stage? Would those clients that support dns-01 renew an existing certbot sourced cert?
Happy to tear it all up and start again if required.
all the Bash and Go clients in the alternate clients support the DNS challenge, and I know some of them can be used to use / renew existing certbot sourced certs, yes.
All Perl clients support it too 
There should be no actual issues in mixing or switching from one client to another, but I think only the certbot would be actually trying to configure the server for you as well (correct me if I’m wrong). So if you are capable of changing the server configurations manually, it doesn’t really matter what client you are using to get the certificates.
Almost all domains that Let's Encrypt issues for are for sites that we've never heard of and that are operated by people who are strangers to us. There's no authoritative way to confirm whether someone really does or doesn't control a site unless they can make some publicly-visible change that we can see over the Internet. The fact that we were able to see such a change when we challenged the certificate applicant to make it is what we're attesting to when we issue a certificate.
If we didn't require those checks for each name that we issue for, people would definitely obtain misissued certificates on a pretty large scale by simply claiming that the sites were on a local network and not visible to the Internet as a whole. While we could prevent some of that misissuance through our blacklist of names that we refuse to issue for (or with the CAA protocol), we've simply never heard of the overwhelming majority of sites that people try to obtain certs for, so we would have no basis on which to make that decision.