For this to work 'somehost' needs to be in the cert, as a SAN entry.
The CSR still contains the fqdn as well, and it may contain more than one shortname.
If the CSR contains these, will LE respect that and issue for it?
(This obviously implies DNS validation).
Secondly, when the request is sent, is the information - the internal hostname and the domain name (identifying the company) - essentially now public? On an accessible list somewhere?
Even if not public information, is the data stored by LE?
Privacy implications pertain.
Thanks. Disappointing. Sort of rules out LE then. 'somehost' is indeed not globally unique, but it is unique within the realm its used: the company network.
Getting users to type https://somehost.company.domain every time when 'company.domain' is the only value ever used internally is a big ask. and would be rejected.
Currently we have an internal CA and we issue certs with it with CN=somehost.company.domain and with SAN entries, DNS.1=somehost and DNS.2=somealias, DNS.3=somehost.company.domain and so on.
We're trying to avoid the management overhead of an internal CA. Looks like not possible. Pity.
Sorry about that. It looks like you're already doing what I was about to suggest, so I have little further to offer. I mean, you could use an internal DNS map (hosts file) from the short names to the FQDNs so your users wouldn't have to type out the FQDNs. This would allow you to certify the FQDNs as usual. For privacy, the short names (only visible in your network) wouldn't even have to match the FQDNs in the slightest. You could call the subdomains of the FQDNs sub1, sub2, ... for example.
For every public CA the realm is "the world wide web". They have to adhere to the rules of the CA/B Forum otherwise their root certificates could (would!) be rejected from browsers. Thus: this is not Let's Encrypt specific.
So to be clear. If I create a CSR with CN=somehost.my.domain and complete validation via dns I’ll get a LE Cert back in the established way?
But if I send that CSR and include SAN entries of DNS.1=somehost and DNS.2=somehost.my.domain I’ll get some response saying CSR invalid? Or I’ll get back a cert with the short name SAN entry removed?
You would only include the FQDNs in the CSR. Internally, you could map those FQDNs to anything you like, so the subdomain name of the FQDN would not need to have any correlation to the internal name. Think of the subdomain as an ID and the internal name as a nickname. The hosts file (or whatever) in your network just maps the two together. Do you really need the short names on the certificate(s) for some reason or would the certificates simply functioning suffice?
The reasoning behind this is you may have a server named "somehost" inside your network and a certificate that is valid for it. I could also have a server named that inside my network. It wouldn't be right for my computer to accept your certificate because it means something entirely different in my network.
If you have it on somehost.company.domain, assuming it's an ICANN TLD, it would mean the exact same thing to me an it would you.
Apologies in advance for the rant. I'm currently suffering through the fallout of decisions like this and got a bit carried away.
I realize you may not have the authority to push for this type of change. But in my opinion, this is a terrible practice and causes no end of problems for not a lot of gain.
It forces you to use hacks like domain search order lists. If you have many domains in the search list, it can cause excessive failed lookups on your DNS servers and make resolution take longer. In some cases, lookups may even timeout. It creates ambiguity where there shouldn't be any. It makes conversations about DNS resolution being broken involve extra teams that manage the workstations instead of just the DNS folks. You have conflicts with things like NetBIOS and mDNS
Modern browsers make this argument moot. Any site people go to regularly will be cached in the URL history within a few visits such that as soon as people start typing the first few characters of the hostname, it will autocomplete before they're even done typing the first label. For a url like https://somehost.company.domain, they'd likely only have to type s, o, m, <enter>. Even if you happen to be using some sort of legacy browser that has terrible URL autocompletion, bookmarks have been around since the web's dark ages. Normal people shouldn't need to type full URLs pretty much ever for anything they visit often.
What? @griffin, I don't get to tell you your wrong?!?!? - LOL
I don't understand your hack/workaround - and I workaround hacks and even hack workarounds!
WINS went away at the turn of the century.
DNS replaced it and runs the whole Internet now.
DNS requires FQDN (let's not talk about the whole DNS short name stuff).
As @rmbolger pointed out, they would only need to type it once and the browser would remember it.
Or they would only need to add it to their favorites (once).
If once is too much, then a GPO could place a shortcut on their desktops with all the favorites.
Here is a hack/workaround:
Required:
Internally managed DNS.
Internally managed web server.
Internally trusted CA
Steps to a successful hack/workaround:
create "short" entries in DNS that all point to the IP of the web server.
[as long as the "short names" don't match valid TLDs - like "com","net","org","museum",...]
create an HTTP vhost config to redirect all "short" names to "$host"+"."+"internal.domain"
[exact concat string will vary from the provided example & you may want to redirect to HTTPS]
obtain a cert from internal CA for "*" [to cover all possible "short names" (only)]
[only need to do this one time - until the cert expires, so make that as long life as possible]
create an HTTPS vhost config to redirect all names to "$host"+"."+"internal.domain"
[(again) exact concat string will vary from the provided example]
It almost sounded like to me that @johnmon was using internal names that would be dangerous/concerning/etc if leaked. Hence the question about privacy of certificates issued, which I answered in the first reply. Never knew mapping to convenient names would cause this many headaches with using certificates. Figured it was an easy kludge. Live and learn.
It appears to me like @JuergenAuer's solution of using a wildcard certificate is the wisest (and the most elegant) in terms of masking the internal host names. No need to list them (or even have them exposed at all) if the are never directly certified at all.
Wildcards can overcome the privacy issue.
But with an Internal CA, I really don't understand the need for using externally/globally trusted cert(s) inside the local network.
I'm just trying to provide a possible solution to the question posed - not re-engineer it.
To expand upon @ski192man's answer, this is all intentional: in order to accept short names as globally unique, the client machines need to be modified to know that they are supposed to be on the specific corporate network. Otherwise, one company could perform an attack against another company, because there wouldn't be a way for the client machines to distinguish between the meaning of mailserver on "the corporate network that I'm supposed to be on" and mailserver on "the corporate network that I'm not supposed to be on".
Most often, this is done by creating an internal CA. The publicly-trusted CAs are not allowed to help by issuing certificates for only-locally-unique names because they don't have a way to guarantee that those certificates are only ever consumed by client machines in the proper setting or context. You could say "I promise that if Let's Encrypt gives me this globally-ambiguous but locally-unique certificate, I will only even use it on my organization's network", but Let's Encrypt can't ensure that everyone who makes that promise intends to keep it, and can't contain the damage if someone loses control of such a certificate and matching private key. (The stolen certificate and key could then be used to attack various other networks around the world.)
It might be good for corporate applications if browsers provided a simpler way to do this than operating a custom local CA, but it's not clear that there's a particularly safe alternative that would be simpler to administer.
