Hi everyone,
I am a newbie in the field of certificates and would like to understand if it is feasible to certify my intranet domain without exposing the domain itself on the internet.
I have read some discussion about it and there are conflicting opinions. I understood that the correct way is the DNS-01 challenge but as a neophyte I would need someone to show me the steps to get the job done.
The domain is on Microsoft servers and is like * .intranet.mydomain. The web apps I use are many and on different platforms and as you know the latest versions of web browsers no longer accept self-signed certificates. Any advice is welcome. Thanks in advance to all those who want to help me.
1 Like
Hi @pepsy80
start with the required basics:
Then select a client and use it:
If you use the client correct and if your configuration is good enough, you will have a working certificate.
1 Like
Thanks for Quick reply.
I read those Pages before posting but i dind't really find a solution. My question Is : how to create a working (wildcard?) certificate for my intranet using certbot, or some other tool, using dns-01 challenge. The other question Is : Is It possible?
2 Likes
You have to select a client and use that client. That's the job you have to do.
Well, first, you need a public domain--it needs to be registered, and DNS records need to exist. Then, request a cert using your favorite client using the DNS challenge. It will tell you to create a DNS TXT record for _acme-challenge.yourdomain with a specified (long, apparently-random) value. Create that record, wait a few minutes, tell the client to continue. If you created the record properly, you'll get the cert.
The problem is that this method requires manual intervention at least every 90 days, which is kind of the opposite of what Let's Encrypt is trying to do--what you really want is for your client to have the ability to update your DNS records automatically. This is something that depends both on your DNS host and your client--AFAIK, acme.sh has the best support for a wide variety of DNS hosts:
6 Likes
So if Domain isn't public i can't generate a valid certificate. Is this correct?
1 Like
Correct. Let's Encrypt needs to connect to something, either a webserver on port 80/443 or a DNS server. If everything is private and Let's Encrypt can't connect to anything, it can't validate the hostname and it can't issue a certificate.
I'm not entirely sure how we can improve the documentation any further, it should have been clear. If you can and are willing to, please tell us what wasn't clear about the documentation so we might improve them.
2 Likes
Sorry, the DNS-01 challenge misled me.
Thank you all for your time , i suspected this thing but i wanted to be sure.
1 Like
For windows, check out https://certifytheweb.com (a GUI I develop for windows). It has a bunch of supported DNS validation options. https://docs.certifytheweb.com/docs/certificate-process
For DNS validation to work your intranet hostname needs to be part of a public zone, so if you're company has example.com and your intranet server is yourintranet.example.com, the DNS validation will require a public TXT record be populated called _acme-challenge.yourintranet.example.com and when that validates OK you can get a certificate for yourintranet.example.com. For the certificate to be valid in your users browsers, your users will need to access the site as yourintranet.example.com, not just yourintranet.
Note that if you don't want to mess with your DNS much you can use the acme-dns option for DNS validation, which means you end up with a CNAME you have to create once in your DNS, but subsequent updates happen in the acme-dns server (which you can host yourself or use you can use a hosted one).
Could you please explain how the DNS-01 challenge misled you? Can we further improve the documentation?
There is no mention about if the DNS server must be public. In my mind the ACME bot do the job and read the value af any record or txt on my local DNS server. My mistake for ignorance on the subject.
The first link
has your complete answer:
There are two steps to this process. First, the agent proves to the CA that the web server controls a domain. Then, the agent can request, renew, and revoke certificates for that domain.
So the CA must be able to check minimal your DNS.
Directly -> dns validation
To find an ip address -> checking that ip address using http validation (or alpn).
1 Like
Thanx for explaination. My intranet is intranet.local and website is mycompany.com .
I have a wildcard cert *.mycompany.com and i would like to make a wildcard cert for my intranet.
I'm trying figure out and find the best way.
You can't, because .local isn't a public suffix, so it's not your domain.
Hmm, I see. Which documentation pages did you read? For example, if I look at the Challenge Types page, I read the following statement:
After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at
_acme-challenge.<YOUR_DOMAIN>. Then Let’s Encrypt will query the DNS system for that record.
It indeed does not specify explicitely that the DNS server needs to be public. But it is implicitly stated, because if the DNS server isn't public, then how can Let's Encrypt query it?
Perhaps the confusion arises that it isn't clear with what is meant with "Let's Encrypt"? If you only read this document, perhaps you might confuse the Let's Encrypt validation server with the ACME client you're using.
I've seen people confused about this many times here on the forum. If someone can find a clear and concise way to describe this that would help people get it, I think that would be a huge service!
@JuergenAuer's note above about a local name not being "your domain" is an important insight that can also be counterintuitive for some people. That is, a public certificate authority is always making statements only about the global meaning of a name. But people may not have the intuition about why that should be.
3 Likes
For internal company wide use (of an internal server name) an option is to run your own CA using smallstep CA or any number of local CA products - you then need to get your internal CA root cert trusted on all the internal machines, then it can sign the certs for the intranet services etc. I believe you can actually script it all just using openssl to generate stuff, the key is getting your root cert trusted on all the machines that need to use it.
The easiest way is to simply have a public name for your intranet that uses your public domain (the intranet site does not need to be publicly accessible) and move everyone to use that, then you can just use Let's Encrypt with any ACME client and use DNS validation to get your wildcard (or a single cert per intranet service is best) etc.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.