Getting a new certificate

My domain is: This domain used for testing purposes

I ran this command:

sudo certbot --apache on a Mac Os machine

It produced this output:

Type: dns
Detail: No valid IP addresses found for

My web server is (include version): Local Web Server through port forwarding
DNS server - Google Domains

The operating system my web server runs on is (include version):
Apache 2.4.33

My hosting provider, if applicable, is: DNS Server - Google Domains; Web Host server: Local server on a Mac OS device

I can login to a root shell on my machine (yes or no, or I don’t know): Yes;
Http site working fine as well.

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): I am using telnet command line

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
Certbot 0.39.0

Any help to address this issue would be appreciated. Thanks.

That website’s current IP address is, which is a private address that works on your LAN but isn’t accessible from the Internet. Certbot’s apache plugin uses HTTP validation, which means Let’s Encrypt’s validation servers have to be able to connect to your website from the Internet, and they can’t unless it has a public IP.

If it’s feasible to install Certbot’s DNS plugins on OS X, and if you use Google Cloud DNS or another DNS service with a suitable API, you might be able to use DNS validation, which validates using a TXT record and doesn’t connect to your web server directly.

Does your server have a public IP address? If you’re running it at home, is port 80 accessible, and can you port forward it to your server?

If the domain is for testing, what kind of testing are you doing? Do you have another domain using another web server that does have a public IP?

1 Like

Thanks for getting back to me. Yes, I do have the port forwarded and this is supposed to be a public IP address. I have not only opened the port 80, but also 443 for this particular IP address.

For that matter, I tried the .local site as well the first time when I ran this command, and the certbot command did not even allow me to run the certificate command as it happened to be a local site.


Your DNS records currently don’t have your public IP, though. If you change to your public IP, and nothing else goes wrong, it should work.

You can’t get publicly trusted certificates from Let’s Encrypt or other CAs for names ending in .local, since they’re not… normal domains.

Since our last communication, I have made some progress, but still seeing some minor errors. If you could shed light on this one, that would be greatly appreciated.

Error Message:

Enabling site /private/etc/apache2/extra/httpd-vhosts-le-ssl.conf by adding Include to root configuration

Created an SSL vhost at /private/etc/apache2/extra/httpd-vhosts-le-ssl.conf

Deploying Certificate to VirtualHost /private/etc/apache2/extra/httpd-vhosts-le-ssl.conf

Error while running apachectl configtest.

AH00526: Syntax error on line 13 of /etc/letsencrypt/options-ssl-apache.conf:

Setting Compression mode unsupported; not implemented by the SSL library

Rolling back to previous server configuration…

Error while running apachectl configtest.

AH00526: Syntax error on line 13 of /etc/letsencrypt/options-ssl-apache.conf:

Setting Compression mode unsupported; not implemented by the SSL library


** - We were unable to install your certificate, however, we**

** successfully restored your server to its prior configuration.**

  • Congratulations! Your certificate and chain have been saved at:


    Your key file has been saved at:


    Your cert will expire on 2020-02-06. To obtain a new or tweaked

    version of this certificate in the future, simply run certbot again

    with the “certonly” option. To non-interactively renew all of

    your certificates, run “certbot renew”

What does that line say?

There is a public IP now:


Try obtaining a cert just for that single domain (option #2).
[after you fix the line 13 problem]

Thanks, Rudy.

I was able to get the certificate working by getting the certificate issued one domain at a time.

Further, making changes in the SSL file to accommodate for the generated .pem files addressed the other issue.

I will get in touch again, if I have further issues with the SSL certificate.

Good weekend!

1 Like


I am trying to set Let’s encrypt SSL for a domain that is not on the default http port. When I tried to add SSL certificate, I got the error message that the domain is not pointing to the default http port. Is there a way to fix this? If yes, could you outline the steps for me to fix this issue?

Thanks in advance for your assistance,


Hi @skidambi75,

The port numbers are relevant in the way the Let’s Encrypt certificate authority checks your control over the domain name. If you haven’t already seen it, please take a look at this document

and consider how you might be able to make any of these methods work in your environment. In particular, note that the HTTP-01 challenge method, which is the most used, always starts with a connection on port 80. The validator is willing to follow an HTTP redirect, including to a different machine, but only to port 80 or port 443.

Thanks for getting back to me.

Suggestion: There are times when we can’t use the default ports for different reasons. For that reason, it would be helpful to have the option to include other ports, not restricting to default ports for adding SSLs.


I believe this is a CA/B Baseline requirement which CAs must follow in order to be in compliance.

It’s outlined in Agreed-Upon Change to Website Confirming the Applicant’s control over the FQDN by confirming one of the following under the “/.wellknown/pki-validation” directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port: 1. The presence of Required Website Content contained in the content of a file. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page, or 2. The presence of the Request Token or Random Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request.

And authorized port was defined as

Authorized Ports: One of the following ports: 80 (http), 443 (http), 25 (smtp), 22 (ssh).

File link:

Yes, you are correct. 443 is https. However, shared systems could make certain ISPs take a cautious approach to opening port 80, which limits users from using that port.

By the way, I thought that we can verify the ownership of the domain manually using the DNS text record in cases when the port is not 80. Some SSL providers offers this option.

Thanks and regards -


1 Like

Yes, that’s also possible (and available) for Let’s Encrypt(DNS-01).
What I was referring is the HTTP validation (HTTP-01).
Actually Let’s Encrypt does have a easy way to validate against port 443 initially, by TLS-SNI-01 but was disabled due to security issues. Currently you could use TLS-ALPN to validate your domain (Also from port 443), but the clients supporting this feature is rare (relatively).

1 Like