Please fill out the fields below so we can help you better.
My domain is: *.sma.com
I ran this command: ./certbot-auth
It produced this output: DNS problem: NXDOMAIN looking up A for twc.sma.com
My operating system is (include version): opensuse 42.1
My web server is (include version): apache 2.4
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know): Yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No
We use the domain “sma.com” for our local network. The domain unfortunately is also registered and is in use on the Internet; the domain has passed through 4 or 5 owners since we established our local network in 1998. Generally this is not an issue as our local DNS server knows what’s what.
cert-bot-auth, OTOH, apparently uses a non-local DNS server to resolve the domain names of interest, which results in the type error indicated above.
Is there a way to tell certbot-auth to use the local DNS server rather than its default one?
Let’s Encrypt is a public Certificate Authority for the Web PKI. So far as Let’s Encrypt is concerned, you’re not the owners of sma.com, that’s somebody else. So you can’t be issued certificates for sma.com
All CAs participating in the Web PKI will (or at least should) also refuse you certificates for sma.com because you’re not the true owners. If you need certificates for names in sma.com you will need to either operate your own CA (for which you can make whatever rules you want) or find a private CA which is willing to issue for sma.com even though they know your sma.com isn’t the one on the Internet. They are likely to charge a hefty fee for this, not least because they effectively rule out ever having sma.com or any business which wants to talk to sma.com as a customer.
Oh also, just in case it’s not obvious, a private CA (including your own) would not be trusted by most systems out of the box like Let’s Encrypt is. The rules that let them get that trust are the same rules that don’t let them issue you certificates for names that (as far as the Internet is concerned) aren’t yours.
However, a lot of software can be configured to trust another CA. For example in Windows this can be part of a “Group Policy” configured centrally and installed in all the machines that are part of a Domain. So for your internal use a private CA can be a very practical option.
Also, stop using (someone else’s) global domains in a local network. Best practice is to register a domain and use a subdomain locally, like lan.example.com.
This is indeed very good advice, and not just because of SSL. There are many other things that can go wrong if you use public domains that you do not own for your local network. As an example, the owner of said domain could create DNS records that Windows queries to discover proxy settings, which would essentially let them observe (and MitM) all your traffic, see WPAD Name Collision Vulnerability.