To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
The operating system my web server runs on is (include version): RHEL 7.5
My hosting provider, if applicable, is: N/A
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
The web server resides in our DMZ. Domain jira.c-e.com has a dmz IP address of 10.197.191.236 which was verified by running dig jira.c-e.com A command.
Externally, jira.c-e.com DNS is 170.200.78.236. External traffic for jira.c-e.com is NAT’d to the DMZ address 10.197.191.236
When I run the certbot certonly command, I assume that certbot fails because (internally) jira.c-e.com A record points to the private IP address.
I assume this is a common configuration for web servers. How do I workaround this configuration to generate a certificate?
Thank you very much for any help you can provide.
Thank you for your help.
I will only create a certificate for jira.c-e.com
When I went to document root, I noticed that Certbot didn’t create the .well-known file. For testing purposes, should I create it? Are there instructions somewhere for creating this test file?
I have created the directory for the test and I get 404 error. http://jira.c-e.com/.well-known/acme-challenge/test.txt
I ran the certbot command with verbose and dry-run arguments. The results are attached. I also ran nslookup from the server. Note the difference between our “internal” DNS and public DNS.
Did you create a test.txt file yourself? That's what @JuergenAuer was asking for. It's not something that Certbot would do, but a task for you to make sure that your configuration currently works the way that you expect and the way that Certbot will expect.
Your internal IP-addresses are irrelevant. From outside, I can load your website, so the Letsencrypt-Check has also access to /.well-known/acme-challenge/file-with-a-very-long-token-as-filename
But it's important to know if there is no file-restriction or other problems (suboptimal redirects). So it's helpful if you create manual a file, post the name and we can check this.