That website’s current IP address is 192.168.0.250, 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?
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?
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.
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
18.104.22.168.6 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).
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).
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.
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.
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.
The “error message” image that I had shared in one of the earlier messages pertained to absorpingbrain.org. 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, absorpingbrain.org 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.