Tag Archiv für Apache

Problem mit RedirectPermanent und automatischen Updates von Let’s Encrypt

Meine Scripte zum Erstellen und Erneuern der Let’s Encrypt funktionierte nach einem Serverumzug und ein paar Konfigurationsänderungen nicht mehr. Folgende Fehlermeldung wurde ausgeworfen:

Verifying www.domain.tld...
Traceback (most recent call last):
File "/usr/local/bin/acme_tiny", line 141, in get_crt
assert (disable_check or _do_request(wellknown_url)[0] == keyauthorization)
File "/usr/local/bin/acme_tiny", line 46, in _do_request
raise ValueError("{0}:\nUrl: {1}\nData: {2}\nResponse Code: {3}\nResponse: {4}".format(err_msg, url, data, code, resp_data))
ValueError: Error:
Url: http://www.domain.tld/.well-known/acme-challenge/xr8lBzb_kujRUBCVMwXI7dVLy1m6wrfEkhw-Jr_Mapw
Data: None
Response Code: None
Response: <urlopen error [Errno 8] Name does not resolve>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/local/bin/acme_tiny", line 198, in <module>
main(sys.argv[1:])
File "/usr/local/bin/acme_tiny", line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
File "/usr/local/bin/acme_tiny", line 143, in get_crt
raise ValueError("Wrote file to {0}, but couldn't download {1}: {2}".format(wellknown_path, wellknown_url, e))
ValueError: Wrote file to /usr/local/www/challenges/xr8lBzb_kujRUBCVMwXI7dVLy1m6wrfEkhw-Jr_Mapw, but couldn't download http://www.domain.tld/.well-known/acme-challenge/xr8lBzb_kujRUBCVMwXI7dVLy1m6wrfEkhw-Jr_Mapw: Error:
Url: http://www.domain.tld/.well-known/acme-challenge/xr8lBzb_kujRUBCVMwXI7dVLy1m6wrfEkhw-Jr_Mapw
Data: None
Response Code: None
Response: <urlopen error [Errno 8] Name does not resolve>
Signierung nicht erfolgreich!

Wie ich dann herausgefunden habe, mag Let’s Encrypt nicht mit der Konfiguration Redirect permanent spielen:

<VirtualHost *:80> ServerName domain.tld ServerAlias www.domain.tld ServerAdmin contact@domain.tld DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Redirect permanent / https://domain.tld/ <Directory /var/www/html>    Options FollowSymLinks AllowOverride all Require all granted </Directory> </VirtualHost>

Nachdem ich statt mit

Redirect permanent / https://domain.tld/

das Umschreiben zu HTTPS mittels folgendem Block 

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/.well-known/.*$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

umgesetzt habe, konnte ich wieder Zertifikate anfordern und erneuern.

Ergänzung zum Beitrag Core-Dumps beim Apache Start mit aktiviertem PHP

Welche Auswirkungen die falsche Reihenfolge der PHP Module in der extension.ini haben kann, zeigte sich heute an dem FreeBSD 10 Server, den ich gerade als  Nachfolger aufsetze:

===>>> Starting build for ports that need updating <<<===

===>>> Launching child to install comms/pear-Horde_ActiveSync

===>>> All >> comms/pear-Horde_ActiveSync (1/8)

===>>> Currently installed version: pear-Horde_ActiveSync-2.19.0
===>>> Port directory: /usr/ports/comms/pear-Horde_ActiveSync

===>>> Starting check for build dependencies
===>>> Gathering dependency list for comms/pear-Horde_ActiveSync from ports
===>>> Dependency check complete for comms/pear-Horde_ActiveSync

===>>> All >> pear-Horde_ActiveSync-2.19.0 (1/8)

===>  Cleaning for pear-Horde_ActiveSync-2.19.3
===>   pear-Horde_ActiveSync-2.19.3 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by pear-Horde_ActiveSync-2.19.3 for building
===>  Extracting for pear-Horde_ActiveSync-2.19.3
=> SHA256 Checksum OK for Horde/Horde_ActiveSync-2.19.3.tgz.
===>  Patching for pear-Horde_ActiveSync-2.19.3
===>   pear-Horde_ActiveSync-2.19.3 depends on file: /usr/local/share/pear/.channels/pear.horde.org.reg - found
===>   pear-Horde_ActiveSync-2.19.3 depends on executable: pear - found
===>  Configuring for pear-Horde_ActiveSync-2.19.3
===>  Staging for pear-Horde_ActiveSync-2.19.3
===>   Generating packing list with pear
*** Signal 11

Stop.
make: stopped in /usr/ports/comms/pear-Horde_ActiveSync

===>>> make stage failed for comms/pear-Horde_ActiveSync
===>>> Aborting update

===>>> Update for comms/pear-Horde_ActiveSync failed
===>>> Aborting update

===>>> You can restart from the point of failure with this command line:
       portmaster <flags> comms/pear-Horde_ActiveSync devel/pear-Horde_Core archivers/pear-Horde_Pack textproc/pear-Horde_CssMinify www/pear-Horde_Dav databases/pear-Horde_Db mail/pear-Horde_Imap_Client devel/pear-Horde_Timezone

Nachdem ich auch hier die Reihenfolge der Module entsprechend abgeändert hatte, lief das Update problemlos. Ein Core Dump mit Signal 11 habe ich sonst bislang nur bei defektem Ram oder ähnlichem erlebt. Deshalb wäre ich hier normalerweise nie auf die Idee der falschen Ladereihenfolge der PHP Module gekommen.

Core-Dumps beim Apache Start mit aktiviertem PHP

Seit einiger Zeit kämpfte ich nach nahezu jedem Update von Apache oder PHP damit, daß anschließend mein Webserver beim Starten mit Core Dump die Grätsche machte. Ich habe dann eigentlich immer erstmal PHP komplett deaktiviert, damit die Websites die ohne PHP laufen, nicht beeinträchtigt wurden. Dann habe ich so lange verschiedene PHP Module neu kompiliert, bis es irgendwann wieder ging. Das war teilweise ein langes, nerviges Vorgehen und vor allem war mir trotz ausführlichem Googlen weder die echte Ursache noch die wirkliche Lösung ersichtlich. Das Problem äußerte sich neben dem kommentarlosen Crash des Indianers durch folgende Einträge im PHP-Log:

[15-Oct-2014 01:07:42 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/memcache.so' - /usr/local/lib/php/20121212/memcache.so: Undefined symbol &quot;php_session_create_id&quot; in Unknown on line 0
[15-Oct-2014 01:07:42 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/memcached.so' - /usr/local/lib/php/20121212/memcached.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/igbinary.so' - /usr/local/lib/php/20121212/igbinary.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/soap.so' - /usr/local/lib/php/20121212/soap.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0
[15-Oct-2014 01:07:43 Europe/Berlin] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20121212/wddx.so' - /usr/local/lib/php/20121212/wddx.so: Undefined symbol &quot;ps_globals&quot; in Unknown on line 0

Heute habe ich dann scheinbar besser gesucht bzw. bin endlich auf die offizielle Seite des Moduls gegangen und habe dort tatsächlich die Lösung gefunden:

Abstürze und Startprobleme von PHP können auftreten, wenn die Recode-Extension nach einer der beiden Extensions mysql oder imap geladen wird. Wenn die Recode-Extension vor den genannten anderen geladen wird, tritt das Problem nicht auf.

Nachdem ich das Modul in der /usr/local/etc/php/extensions.ini von fast letzter an die zweite Stelle verschoben hatte, klappte es auch wieder problemlos mit dem Starten des Indianers!

Ich hoffe, damit ist dieses Problem für immer erledigt.

SSL-Zertifikat für Apache und Dovecot bei Startssl.com erstellen

Das israelische Unternehmen StartSSL.com bietet kostenlose SSL-Zertifikate, die von Browsern vollständig akzeptiert werden, weil das Root-Zertifikat von StartSSL.com in eigentlich allen Browsern schon direkt hinterlegt ist.

Zunächst mit dem Browser wieder anmelden, den man beim letzten mal benutzt hat (und hoffentlich ist das kürzer als ein Jahr her, sonst ist das Authentifizierungs-Zertifikat abgelaufen). Dann den Certificates Wizard aufrufen. Als Certificate Target „Web Server SSL/TLS Certificate“ auswählen.  Auf der nächsten Seite mit Skip weitermachen.

Zwischendurch auf dem Webserver mit

openssl genrsa -out hostname.domain.tld.key 4096

den privaten und öffentlichen Schlüssel und mit

openssl req -new -key hostname.domain.tld.key -out hostname.domain.tld.csr

den eigentlichen Certificate Signing Request erstellen. Dann den Inhalt der Datei hostname.domain.tld.csr im Browser auf der nächsten Seite von Startssl.com in das Eingabefeld übertragen. Auf der nächsten Seite die Domain auswählen, zu der das Zertifikat gehört und auf der nächsten Seite die Subdomäne eintragen und den Certificate Signing Request abschicken.

Nach kurzer Zeit findet man dann in der Tool Box unter dem Punkt Retrieve Certificate das beantragte Zertifikat und kann es dann mit Cut&Paste auf den Webserver übertragen und in der Apache Konfiguration eintragen. Das Webserverzertifikat kann übrigens auch problemlos für Postfix und Dovecot genutzt werden!

Bei dem zweiten openssl Aufruf (openssl req) wird man am Schluß nach einem Paßwort gefragt. Sollte man dort eines angegeben haben, dann startet Apache nur, wenn bei seinem Start auch immer das Paßwort des Zertifkats eingetippt wird. Man kann aber dieses Paßwort so wieder wegbekommen:

openssl rsa -in hostname.domain.tld.pem -out hostname.domain.tld.pem.neu

Trailing Slash Problem beim Apache

In groesseren Abstaenden tritt bei mir das „trailing slash problem“ beim Apache auf und jedes mal muß ich neu googeln, um die Loesung zu finden:

Artikel bei O’Reilly dazu, der eigentlich alles wichtige behandelt: http://www.onlamp.com/pub/a/apache/2004/02/19/apache_ckbk.html?page=2

Kurz gesagt: Meistens handelt es sich um eine Fehlkonfiguration des Apache. Und zwar ist entweder der ServerName oder eine Alias-Direktive nicht korrekt konfiguriert. Bei den Aliasen darf nirgendwo ein endständiger Slash eingetragen sein. Sonst ist der Alias immer nur für http://server.tld/alias/ zutreffend und niemals auch bei http://server.tld/alias

Bei mir ist es meistens eine falsche Alias-Konfiguration. Da habe ich dann vermutlich schnell einn Alias eingetragen und dann die Grammatik des Eintrags an eine directory-Direktive angelehnt, die in der Nähe steht.

Verwirrend ist für mich die Grammatik der ScriptAlias-Direktive. Wenn man sich die Apache-Doku dazu vornimmt, dann findet man diese Aussage hier:

„The ScriptAlias directive has the same behavior as the Alias directive“ (es wird dann noch eine Ausnahme genannt, diehat aber mit diesem Problem nichts zu tun. In den Beispielen wird dann aber alle mit endständigem Slash aufgeführt!