Category: Apache

Create certificate for localhost domains on macOS

Step 1: create a self-signed root certificate

First, let’s create a self-signed root certificate:

openssl req -x509 -nodes -new -sha256 -days 390 -newkey rsa:2048 -keyout "RootCA.key" -out "RootCA.pem" -subj "/C=de/CN=localhost.local"
openssl x509 -outform pem -in "RootCA.pem" -out "RootCA.crt"

The parameter -days 390 sets the number of days, this certificate is valid. Starting on September 1st (2020), SSL/TLS certificates cannot be issued for longer than 13 months (397 days), see https://stackoverflow.com/a/65239775.

If this time is too long, you will receive an NET::ERR_CERT_VALIDITY_TOO_LONG error. In the command above, this value was set to 390 days, which works for me.

Step 2: define domains and subdomains that should be included in the certificate

For this, just create a text file named vhosts_domains.ext and insert the following contents:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = *.mixable.blog.local
DNS.3 = mixable.blog.local

This example includes subdomains for a local development environment for the domain mixable.blog.local and all subdomains like www.mixable.blog.local or apps.mixable.blog.local.

If you plan to use a more general certificate e.g. to include all subdomains under *.*.blog.local, this will not work. The definition only supports ‘first level’ subdomains. It would be great, because this saves a lot of additional setup, but unfortunately this is note supported.

Step 3: create the certificate

Now let’s create the certificate:

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=de/ST=State/L=City/O=Organization/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile vhosts_domains.ext -out localhost.crt

Calling the two commands above will create the localhost certificate that includes all the provided domains and subdomains. Your file listing should look like this:

Step 4: make the certificate available for Apache

Depending on your system, copy all those files into the the configuration folder of the Apache installation. In my case, the installation was done with the help of brew, so the local path is:

/usr/local/etc/httpd/cert/

At the end, it’s not important where those files are located, because we no add this path to the vhost definitions. For this, open your vhosts file and link the crt and the key file as follows:

# mixable.blog.local
<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
    ServerName mixable.blog.local
    ServerAlias mixable.blog.local
    ErrorLog "/usr/local/var/log/httpd/localhost-error.log"
    CustomLog "/usr/local/var/log/httpd/localhost-access.log" common
</VirtualHost>
<VirtualHost *:443>
    DocumentRoot "/Users/mathias/Sites/mixable.blog.local"
    ServerName mixable.blog.local
    SSLEngine on
    SSLCertificateFile "/usr/local/etc/httpd/cert/localhost.crt"
    SSLCertificateKeyFile "/usr/local/etc/httpd/cert/localhost.key"
</VirtualHost>

If you have additional vhost definitions, you can add the <VirtualHost *:443> part to every server name entry and use the correct paths to SSLCertificateFile and SSLCertificateKeyFile.

After changing the vhost settings, it is required to restart your Apache server!

Step 5: add the certificates to macOS

When opening a local website, the certificate should be used but you might see a NET::ERR_CERT_INVALID error. This is the case, because modern browsers/systems do not trust self-signed certificates by default. to overcome this issue, we have to add the created certificates to the macOS Keychain Access. For this, open the *.crt files in Keychain Access:

So that they are know by macOS:

And finally, update the trust settings of each certificate to “Always trust”:

You should now be able to use a secure connection between your browser and your local server:

Step 6: additional fixes

The steps above might already work for Chrome and Safari. If you have problems with Firefox, just open settings and go to Privacy & Security. Then you have to import the root certificate file RootCA.crt, so that Firefox knows about your certificate.

OTRS 5: Fatal Error Kernel/ Modules/ AgentTicketZoomTicketID

Recently we switched from http to https for our ticket system OTRS5. After doing so, clicking on the links OTRS sent via email in (customer) notifications, resulted in the error:

Module Kernel/Modules/AgentTicketZoomTicketIDxx.pm not in @INC (/opt/otrs/Custom /opt/otrs/Kernel/cpan-lib /opt/otrs/ /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl

After some digging, we traced the problem back to Apaches RewriteEngine which replaced the “;” chars with “%3b” when someone used a http link (which OTRS sent via email).

The solution was simple: Set HttpType to “https” in SysConfig -> Core.

Imagick und “libgomp: Thread creation failed: Resource temporarily unavailable”

Bei der Bildbearbeitung mit Imagick (PHP) kann es mitunter zu einem Timeout bzw. Internal Server Error kommen und die Grafik wird nicht erstellt. In meinem Fall immer dann, wenn man versucht einen Text in der Grafik mittels Imagick::annotateImage() darzustellen.

Schaut man sich die error.log des Webservers an, dann stolpert man über den Fehler “libgomp: Thread creation failed: Resource temporarily unavailable”.

Was ist das Problem? Imagick scheint mehr Threads für die Bilderstellung beanspruchen zu wollen, als verfügbar sind.

Wie kann man die Anzahl der Threads eingrenzen? Folgende Einstellungen sollten gesetzt werden (hier z.B. über die .htaccess):

SetEnv MAGICK_THREAD_LIMIT 4
SetEnv OMP_NUM_THREADS 4

Ist man sich unsicher, wieviele Threads das System zur Verfügung stellt, dann kann man diesen Wert schrittweise erhöhen (1, 2, 4, 8, …), bis der Fehler auftritt. Die Einstellung sollte auch direkt aus dem PHP-Script heraus mit putenv() möglich sein.

FastCGI und ‘Authorization’ Header

FastCGI scheint in den Standardeinstellungen den Authorization Header zu entfernen. Um diesen dennoch nutzen zu können, gibt es verschiedene Möglichkeiten:

Über .htaccess mit:

RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.+)
RewriteRule ^(.*)$ $1 [E=HTTP_AUTHORIZATION:%1,PT]

Oder:

SetEnvIf Authorization (.+) HTTP_AUTHORIZATION=$1

Oder in der FastCGI Config:

FastCGIConfig -pass-header HTTP_AUTHORIZATION

Apache2, PHP und MySQL über MacPorts installieren

Es gibt hier im Blog bereits eine Vielzahl an Posts zu diesem Thema. Warum? Mit jedem Update von Mac OS X scheint sich wieder etwas zu ändern, sodass die Installation von Apache / PHP / MySQL mittels MacPorts nicht mehr funktionieren möchte.

Was bei den einzelnen OS X Versionen zu beachten ist, ist in den HowTo-Beiträgen auf macports.org bestens beschrieben: https://trac.macports.org/wiki/howto.

Detaillierte Information gibt es auf den Unterseiten zu Apache2, PHP und auch MySQL.

MacPorts und Apache2 unter Yosmite (oder später)

Heute bin ich mal wieder auf ein Problem mit dem Apache2 unter Mac OS X gestoßen. Dabei wollte der über MacPorts installierte Server nicht mehr starten. Stattdessen hatte OS X eine andere Installation von Apache2 gestartet…warum auch immer. Vermutlich lag das am Beta-Update von OS X, welches man als Apple-Developer erhält.

Die erste Anlaufstelle zur Fehlersuche war https://trac.macports.org/wiki/howto/Apache2. Hier gibt es eine ausführliche Beschreibung zur Installation bzw. Einstellung zum automatischen Starten des MacPorts Apache2 Servers. Auf dieser Seite ist auch sehr ausführlich beschrieben, welche Besonderheiten bei den verschiedenen Mac OS X Versionen (OS X 10.8 Mountain Lion and earlier, OS X 10.9 Mavericks, OS X 10.10 Yosemite and later) zu beachten sind.

In meinem Fall half der Abschnitt »Step 4: Activate Apache2« weiter.