Date: Fri, 6 Apr 2018 09:33:06 -0400 From: William Dudley <wfdudley@gmail.com> To: krad <kraduk@gmail.com> Cc: freebsd@dreamchaser.org, freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: my Let's Encrypt certs "broken" overnight! SOLVED Message-ID: <CAFsnNZKt5LCHfL6sJFKxKbjaQQi=HsXwLh-P%2BZEYJqAempx7Gg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Krad, This has been solved. problem domain is FreeBSD 10.3, apache24-2.4.33 I had multiple problems, and an *upgrade* caused *mod_ssl* to start barfing when it saw the problems. The problems: I had njsbmwr.dudley.nu, www.njsbmwr.org, but NOT njsbmwr.org defined in the cert. I was doing a redirect for https://njsbmwr.org but didn't list the cert in the stanza, like this: <VirtualHost *:443> ServerName njsbmwr.org Redirect permanent / https://www.njsbmwr.org/ </VirtualHost> That's wrong, one also needs the lines SSLCertificateFile "/usr/local/etc/letsencrypt/live/ njsbmwr.dudley.nu/cert.pem" SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/ njsbmwr.dudley.nu/privkey.pem" SSLCertificateChainFile "/usr/local/etc/letsencrypt/live/ njsbmwr.dudley.nu/fullchain.pem" Or mod_ssl (and hence apache 2.4) refuse to run. And yes, wild card carts would have been a good thing, but I started down this road 6 months ago. Bill Dudley This email is free of malware because I run Linux. On Fri, Apr 6, 2018 at 7:58 AM, krad <kraduk@gmail.com> wrote: > When you say share the same certificate do mean that the cert has multiple > sites defined in it? > Could you supply the output of the following? > > certbot certificates > > > > The <VirtualHost> directive defines where that particular vhost binds > logically on the hosts network stack, where as the servername defines the > host that the vhost responds at the application level. Therefore having > *:433 defined is fine > > Is there any chance of any .htaccess file lurking under the docroot that > maybe polluting the apache config. > > Also its worth noting letencrypt do wild card certs now!! > > > > On 4 April 2018 at 04:56, Gary Aitken <freebsd@dreamchaser.org> wrote: > >> On 04/03/18 07:48, William Dudley wrote: >> >> I had letsencrypt certs for most of the sites I host, and they were >>> working fine until a recent upgrade -- either apache 2.4 or openssl >>> changed and now things are hosed. >>> >>> An example: >>> >>> I host www.njsbmwr.org. I have a "test" URL for development, >>> njsbmwr.dudley.nu. Both share the same certificates, or at least, >>> they used to. >>> >>> Now, if I uncomment the <VirtualHost *:443> section for >>> www.njsbmwr.org, apache throws an error and won't start. If I >>> comment the section out, apache is happy but www.njsbmwr.org doesn't >>> serve https pages. >>> >>> njsbmwr.dudley.nu has almost the identical <VirtualHost *:443> >>> section, and it works fine as https://njsbmwr.dudley.nu >>> >>> The apache error I get when I enable the <VirtualHost *:443> section >>> for www.njsbmwr.org is: >>> >>> [Tue Apr 03 09:13:29.141783 2018] [ssl:emerg] [pid 49861] AH02572: >>> Failed to configure at least one certificate and key for >>> njsbmwr.org:80 [Tue Apr 03 09:13:29.141947 2018] [ssl:emerg] [pid >>> 49861] SSL Library Error: error:140A80B1:SSL >>> routines:SSL_CTX_check_private_key:no certificate assigned [Tue Apr >>> 03 09:13:29.141982 2018] [ssl:emerg] [pid 49861] AH02312: Fatal error >>> initialising mod_ssl, exiting. AH00016: Configuration Failed >>> >>> Here's the <VirtualHost *:443> section that causes failure: >>> >>> <VirtualHost *:443> ServerAdmin webmaster@dudley.nu ServerName >>> www.njsbmwr.org DocumentRoot /usr/local/www/njsbmwr.dudley.nu Alias >>> /.well-known/ /usr/local/www/.well-known/ ScriptAlias /cgi-bin/ >>> "/usr/local/www/njsbmwr.dudley.nu/cgi-bin/" SSLEngine on >>> SSLCertificateFile \ "/usr/local/etc/letsencrypt/live/ >>> njsbmwr.dudley.nu/cert.pem" SSLCertificateKeyFile \ >>> "/usr/local/etc/letsencrypt/live/njsbmwr.dudley.nu/privkey.pem" >>> SSLCertificateChainFile \ "/usr/local/etc/letsencrypt/live/ >>> njsbmwr.dudley.nu/fullchain.pem" SSLOptions +StdEnvVars BrowserMatch >>> "MSIE [2-5]" \ nokeepalive >>> ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 CustomLog >>> "/var/log/njsbmwr.dudley.nu-httpd-ssl_request.log" \ "%t %h >>> %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" Header set >>> Content-Security-Policy "default-src 'self'; script-src 'self' 'u >>> nsafe-inline' pagead2.googlesyndication.com www.google-analytics.com >>> *.cloudflar e.com www.paypal.com; img-src 'self' *.crystalbrook.com >>> www.paypalobjects.com" Header set X-Frame-Options SAMEORIGIN Header >>> set X-XSS-Protection "1; mode=block" Header set >>> X-Content-Type-Options nosniff ErrorDocument 404 >>> /errormessages/oatmeal_404.html ErrorDocument 500 >>> /errormessages/oatmeal_500.html ErrorDocument 503 >>> /errormessages/oatmeal_503.html ErrorLog >>> /var/log/njsbmwr.dudley.nu-error_log CustomLog >>> /var/log/njsbmwr.dudley.nu-access_log combined <Directory >>> "/usr/local/www/njsbmwr.dudley.nu"> Options +ExecCGI +FollowSymLinks >>> +Includes +Indexes -SymLinksIfOwnerMatc h AllowOverride All </Directory> >>> <Location /> Order allow,deny Allow from all </Location> </VirtualHost> >>> >>> The ONLY difference between this section, that doesn't work, and the >>> section that DOES work is the ServerName line: >>> >>> < ServerName njsbmwr.dudley.nu --- >>> >>>> ServerName www.njsbmwr.org >>>> >>> >> Not sure this will help, but it might be worth trying. >> I had a somewhat similar but not exactly the same issue and resolved >> it by being more explicit in the VirtualHost assignments. You might >> try doing each separately and pointing to the same certs: >> <VirtualHost www.njsbmwr.org:443> >> ... >> </VirtualHost> >> and repeat for njsbmwr.dudley.nu:443 >> Apache 2.4 (not sure about earlier releases) uses the first match it >> finds for the <VirtualHost>. So *:443 will match both, and the server >> name won't match for one of them. >> >> Gary >> >> >> _______________________________________________ >> freebsd-questions@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-questions >> To unsubscribe, send any mail to "freebsd-questions-unsubscribe >> @freebsd.org" >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFsnNZKt5LCHfL6sJFKxKbjaQQi=HsXwLh-P%2BZEYJqAempx7Gg>