What are my options of getting a valid cert?

Help
#1

We have an internal development network that we use a domain format like machine-01.int.enterprise.com. None of these servers are exposed to the internet. We have our own local CA on that network, but we can't necessarily control all of the client machines to give them our cert, this means that clients that use the apps/websites on these servers they all get prompted with the "accept the cert" error because...obviously its not signed by a known CA.

On this internal network we have NO control over enterprise.com domain as that's managed by our enterprise IT and don't want to give us any certs or anything as this is a separate network.

I was told that I could register basically any domain and use DNS-01(?) to validate a cert and provide it to my servers and then they would be correctly signed?

So how would this work? Would this work? So for example:

  1. I have machineA.int.enterprise.com that people navigate to
  2. I register int-enterprise.com from Google and I use DNS-01 (?) to validate a cert for machineA.int.int-enterprise.com
  3. I give machineA.int.enterprise.com, the machineA.int.int-enterprise.com cert to nginx
  4. Then when people visit machineA.int.enterprise.com there is a redirect to machineA.int.int-enterprise.com?
    OR
  5. Could I do something like machineA-validcert.int.enterprise.com with the valid cert and then when people go to that new URL the valid cert would work?

The only main requirements I would have is that users don't use the new int.int-enterprise.com domain and to continue to use the regular domain.

Any suggestions on handling this?

1 Like
#2

That would only work if people visit machineA.int.enterprise.com through HTTP, not through HTTPS, as that would present them the internal CAs certificate or it would give them a certificate error about mismatching hostnames (see below:).

That would result in a certificate error for the user, as those two hostnames wouldn't match.

Why would that work? You can't just make up a new hostname which isn't included in the certificate and magically make it work I'm afraid. This would result in a certificate error about mismatching hostnames.

2 Likes
#3

Do you have DNS control over int.enterprise even if you don't have control over the main enterprise domain?

If not, would "enterprise IT" be willing to delegate _acme-challenge.int.enterprise to DNS servers that your "team" controls?

2 Likes
#4

Honestly, I'm not sure how it would or why it would. I was discussing this problem with one of the app developers and they were saying that this might be an option. I wasn't clear on how this would function.

Do I have any options for getting a valid cert to work on this machine without changing the int.enterprise.com domain that these machines are already on?

1 Like
#5

Unfortunately, we do not. No, they won't do anything for us since this is a lab network.

1 Like
#6

Please read:

and:

If you understand how Let's Encrypt works, you can also work out what could work and what doesn't work.

But the TL;DR is: Let's Encrypt needs to be able to verify a specific token through some publically available method. This can either be the host itself through a publically available IP address or a publically available DNS server.

Much is possible, such as redirects in the case of the http-01 challenge (but that would require a publically available IP address to "bootstrap" the whole thing) or "redirect" DNS queries with aid of DNS zone delegation with NS records or a CNAME for the challenge host, like @petercooperjr already suggested.

Also a good reading:

3 Likes
#7

IMHO, the best option would have corporate IT give you a dedicated subdomain - like int.enterprise.com - that you would have full control over with a DNS delegation.

The second best option, would be to run something with autocert on int.enterprise.com and the subdomains, and then just have those serve redirects to the int-enterprise.com domains

2 Likes
#8

The problem is, nothing with *.enterprise.com will work.

1 Like
#10

Would I be able to run autocert on int.enterprise.com even though I don't control enterprise.com?

1 Like
#11

Perhaps I'm not understanding what this means, but if this would have been possible, the whole issue of this thread was resolved, right? The problem is, the OP can't issue any certificate for int.enterprise.com at all.. I don't know how using autocert would resolve this.

2 Likes
#12

let me try to clarify a few thigns:

  1. example.com needs to be a registered domain on the public internet. if your organization does not own example.com, it is a dealbreaker.

  2. in order for you to have a https connection to any subdomain under example.com - whether it is to host the content or redirect to the internal-example.com domain, one of three things needs to happen:

  • you can control public DNS for example.com, or
  • the people who control public DNS for example.com delegate a public zone to you. for example, they could delegate control of internal-a.example.com to you; then you run an acme-dns instance to control that. you would then be able to issue certificates under the internal-a.example.com namespace.
  • the servers are available on the public internet and can run an autocert system (or certbot)

The easiest way for you to accomplish your goals is to have the IT team delegate the DNS admin of a namespace to you. If they can't do that, and you can't control the DNS of the main records, and all the domains are on the private network (not public internet), then you have no options that I am aware of.

2 Likes
#13

I should have been more clear. The idea is the IT department would put the domains on the public internet with an autocert server, and that server would simply get the cert and redirect from int.enterprise.com to int-enterprise.com. The IT department keeps and controls the primary TLD - but must run an autocert server to redirect it to the secondary TLD.

it's not as good as the first option (subdomain namespace delegation), but it's the easiest way to https->https redirect from the primary to secondary domain. otherwise they can only implement a http->https redirect

3 Likes