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?


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.

1 Like

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


I have had installed a SSL certificate that was fully functional for a week or two until earlier in the evening and suddenly, now Chrome and a couple of other browsers are throwing out an error message. When I checked the validity of the certificate, it is still valid for at least another 11 months, and it appears nothing has changed between earlier this evening and now. I would appreciate any suggestion in this regard to fix this issue.


Common Name (CN)

Organization (O)


Organizational Unit (OU)


Issued By

Common Name (CN)

Organization (O)


Organizational Unit (OU)


Validity Period

Issued On

Saturday, November 16, 2019 at 4:36:36 PM

Expires On

Sunday, November 15, 2020 at 4:36:36 PM

Hi @skidambi75

your domain is invisible, only timeouts -

Your ip is now correct. But I don't see the certificate.

Is your Apache running?

There is a new certificate:

Issuer not before not after Domain names LE-Duplicate next LE
Let's Encrypt Authority X3 2019-11-26 2020-02-24, - 2 entries

so you should have one.

certbot certificates
apachectl -S

Thanks for getting back to me. We had some maintenance work last night, and should have the assigned server for this domain up and running soon. However, prior to that, I was getting an error, which I had shared in the last message.

Yes, after the initial hiccup which led to my first message to your team a week or so ago, I reinstalled the apache and it started working fine until I started having issues last evening.

Here is a screenshot of a functioning padlock prior to the current issue.

From my perspective, and are currently using a valid Let’s Encrypt certificate issued on November 26.

The “VAL-U-PRO” certificate in your post was not issued by Let’s Encrypt. There’s no record of it in public Certificate Transparency logs, so it’s most likely not from any publicly trusted CA.

Are you still experiencing issues?

Do you know who or what “VAL-U-PRO” is? Is that your company? The operator of the networks at issue? Some kind of security software?

Do you have a certificate like that installed on your server? Or other servers?

It seems likely that the connections aren’t going where they’re supposed to. Maybe antivirus or other local ‘security’ software is intercepting them (badly). Or corporate network monitoring systems are doing so (again, badly). Or perhaps a NAT or port forwarding issue or a DNS or hosts file misconfiguration mean that the clients are connecting to the wrong server.

1 Like


The “error message” image that I had shared in one of the earlier messages pertained to I am not sure where “val-u-pro” ssl discussion came from.

The val-u-pro site that also belongs to us uses the ssl offered by the hosting provider. Whereas, is currently hosted within our server that we built recently and utilized letsencrypt. We had issues with this certificate that led us to this communication. While we were waiting for your team’s response, we also cleaned the settings from our end and restarted the server that took care of the issue.

Now, we are seeing the padlock on chrome browser after the restart of the server, and also added it to the whitelist in Firefox, which enabled padlock for Firefox as well.

Thanks for getting back to me.



From post #14:

That is our organization name. It has nothing to do with the issue that we faced. As you know, it is one of the common fields included part of setting up a new certificate.