Problem with Let's Encrypt - can you help me?
I am trying to install Let's Encrypt on my Centos server (after restart), but I keep getting this error: Problem binding to port 80: Problem binding to port 80: Could not bind to IPv4 or IPv6.
Any ideas for a fix?
21 Replies
Is it possible one of my network admins (I outsource this) changed a port for security and is giving me this error?
scrane
Linode Staff
Just to make sure, can you copy the command you are running here as well as the full error message?
scrane
Linode Staff
Can you also provide us with the output of netstat -plunt just to see what is listening on port 80?
You bet - I REALLY appreciate this:
sudo -H ./letsencrypt-auto certonly --standalone -d fetch123.com -d www.fetch123.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for fetch123.com
http-01 challenge for www.fetch123.com
Cleaning up challenges
Problem binding to port 80: Could not bind to IPv4 or IPv6.
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:20000 0.0.0.0:* LISTEN 25710/perl
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 26542/dovecot
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 26542/dovecot
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 26462/mysqld
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 3841/master
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 26542/dovecot
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 26542/dovecot
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 25015/perl
tcp 0 0 45.79.141.135:53 0.0.0.0:* LISTEN 13376/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 13376/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 26073/sshd
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 13376/named
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 3841/master
tcp 0 0 127.0.0.1:8891 0.0.0.0:* LISTEN 3773/opendkim
tcp6 0 0 :::993 :::* LISTEN 26542/dovecot
tcp6 0 0 :::4321 :::* LISTEN 3806/pmtahttpd
tcp6 0 0 :::995 :::* LISTEN 26542/dovecot
tcp6 0 0 :::2500 :::* LISTEN 3805/pmtad
tcp6 0 0 :::110 :::* LISTEN 26542/dovecot
tcp6 0 0 :::143 :::* LISTEN 26542/dovecot
tcp6 0 0 :::80 :::* LISTEN 28424/httpd
tcp6 0 0 :::53 :::* LISTEN 13376/named
tcp6 0 0 :::22 :::* LISTEN 26073/sshd
tcp6 0 0 ::1:953 :::* LISTEN 13376/named
tcp6 0 0 :::443 :::* LISTEN 28424/httpd
udp 0 0 127.0.0.1:323 0.0.0.0:* 26968/chronyd
udp 0 0 0.0.0.0:46064 0.0.0.0:* 26599/avahi-daemon:
udp 13824 0 0.0.0.0:5353 0.0.0.0:* 26599/avahi-daemon:
udp 0 0 0.0.0.0:10000 0.0.0.0:* 25015/perl
udp 0 0 0.0.0.0:20000 0.0.0.0:* 25710/perl
udp 0 0 45.79.141.135:53 0.0.0.0:* 13376/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 13376/named
udp6 0 0 ::1:323 :::* 26968/chronyd
udp6 0 0 :::35556 :::* 3805/pmtad
udp6 0 0 :::53 :::* 13376/named
scrane
Linode Staff
Hmm. Just to get your SSL certificate installed right now, let's try running this series of commands:
service httpd stop
cd /opt/letsencrypt
sudo -H ./letsencrypt-auto certonly --standalone -d fetch123.com -d www.fetch123.com
service httpd start
Let us know how that turns out.
I think this is good news:
IMPORTANT NOTES:
Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/fetch123.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/fetch123.com/privkey.pem
Your cert will expire on 2018-08-13. To obtain a new or tweaked
version of this certificate in the future, simply run
letsencrypt-auto again. To non-interactively renew all of your
certificates, run "letsencrypt-auto renew"If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
[root@fetch123 letsencrypt]# service httpd start
Redirecting to /bin/systemctl start httpd.service
scrane
Linode Staff
Excellent! I'm glad to hear you have that up and running. I also I might have found a problem that may be related. When I go to www.fetch123.com I get redirected to an invalid domain:
curl -Il http://www.fetch123.com
HTTP/1.1 301 Moved Permanently
Date: Tue, 15 May 2018 20:59:54 GMT
Server: Apache/2.4.6
Location: https://www.www.fetch123.com/
Content-Type: text/html; charset=iso-8859-1
www.www.fetch123 is not a proper redirect. You may want to check /etc/httpd/conf.d/vhost.conf to make sure there are no entries for www.www.fetch123.com listed as a redirect there.
I super appreciate all this help. You rock…
I do not see a file called vhost.conf in my conf.d folder - could it be somewhere else?
Also, does it take time for SSL to kick in - it still shows as expired this morning and I get that awful message:
Your connection is not private
scrane
Linode Staff
You may want to double check /etc/httpd/conf.d/ssl.confto make sure the SSLCertificateFile is listed as being located at /etc/letsencrypt/live/fetch123.com/fullchain.pem and your SSLCertificateKeyFile is listed as being located at /etc/letsencrypt/live/fetch123.com/privkey.pem
Make sure SSLCACertificateFile is has a # before it to comment it out. You can see what it should look like at our SSL configuration guide for CentOS 7
That may also be where you can find the virtualhost redirect, come to think of it. Scan that file for any examples of www.www.fetch123.com
I do not see that fullchain.pem line anywhere at my ssl.conf: This is a test if you can see this on the answer then this worked.
#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443 https
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
SSLSessionCache shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect. Disable SSLv2 access by default:
SSLProtocol all -SSLv2
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
# Speed-optimized SSL Cipher configuration:
# If speed is your main concern (on busy HTTPS servers e.g.),
# you might want to force clients to specific, performance
# optimized ciphers. In this case, prepend those ciphers
# to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
# Caveat: by giving precedence to RC4-SHA and AES128-SHA
# (as in the example below), most connections will no longer
# have perfect forward secrecy - if the server's key is
# compromised, captures of past or future traffic must be
# considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
#SSLHonorCipherOrder on
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
###SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile /home/fetch123/ssl.cert
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
###SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile /home/fetch123/ssl.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxxxxxxxxx'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
I looked in my .htaccess file - could this be the problem:
Redirect to www
RewriteCond %{HTTP_HOST} ^[^.]+.[^.]+$
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ http%1://www.%{HTTPHOST}%{REQUESTURI} [L,R=301]
scrane
Linode Staff
So taking a look at that configuration file, I believe you will want to edit the file. First make a backup of the file with cp /etc/httpd/conf.d/ssl.conf > /etc/httpd/conf.d/ssl.conf.bak, then go into the original /etc/httpd/conf.d/ssl.conf to replace SSLCertificateFile /home/fetch123/ssl.cert with SSLCertificateFile /etc/letsencrypt/live/fetch123.com/fullchain.pem and replace SSLCertificateKeyFile /home/fetch123/ssl.key with SSLCertificateKeyFile /etc/letsencrypt/live/fetch123.com/privkey.pem.
After that restart httpd with systemctl restart httpd
If you don't know how to edit the file, use the command nano and scroll down using the arrow keys until you find what you want to replace. When you're done making the adjustments press CTRL+X, press y to confirm you want to save, and press enter to confirm the name of the file.
scrane
Linode Staff
Yeah, that should be fine. I would just recommend making a backup of the original file.
Okay. I think it is working - is it working on your end?
If so, I want to autorenew. Do you recommend following the Linode guide or some other way?
scrane
Linode Staff
That .htaccess bit does look like it would double up on the www there, but I'm also not adept enough to provide the best way to fix it. You might want to take a look at the Apache redirecting documentation or Our guide on redirecting in Apache to see if that helps you further.
scrane
Linode Staff
Yes! That does look like you have the SSL certificate working properly when I go to https://fetch123.com! With the auto-renew, you can try to set that up as we have configured in the guide. You may need to edit the cron job to be the following, however:
0 0 1 * * systemctl stop httpd | /opt/letsencrypt/letsencrypt-auto renew | systemctl start httpd
That should get around the problem of port 80 not binding properly by shutting down Apache, running the Let's Encrypt command, then starting Apache back up.
I finally got a moment to try and add this cronjob, but I get an error.
Here is the log file:
2018-05-28 08:18:48,323:DEBUG:certbot.main:certbot version: 0.24.0
2018-05-28 08:18:48,323:DEBUG:certbot.main:Arguments: []
2018-05-28 08:18:48,323:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-05-28 08:18:48,339:DEBUG:certbot.log:Root logging level set at 20
2018-05-28 08:18:48,339:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-05-28 08:18:48,341:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module>
sys.exit(main())
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/main.py", line 1315, in main
return config.func(config, plugins)
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/main.py", line 1228, in renew
renewal.handlerenewalrequest(config)
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/renewal.py", line 391, in handlerenewalrequest
disp.notification("Processing " + renewal_file, pause=False)
File "/opt/eff.org/certbot/venv/lib/python2.7/site-packages/certbot/display/util.py", line 491, in notification
self.outfile.flush()
IOError: [Errno 32] Broken pipe
2018-05-28 08:18:48,344:ERROR:certbot.log:An unexpected error occurred:</module>
Any ideas for a fix?