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?
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 192.168.0.250 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
IMPORTANT NOTES:
** - 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:
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
3.2.2.4.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, 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.
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.
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.
