Hoppla, für 'server.host.name:0' wurde kein RSA- oder DSA-Serverzertifikat gefunden?

Ich richte einen neuen Webserver ein, der unter Ubuntu 12.4 ein Dutzend virtuelle Hosts hostet, wobei Apache 2.2.22 mit einer Konfigurationsdatei pro Site verwendet wird. Ich habe alle Konfigurationsdateien auf einmal erstellt und ausgeführt a2ensite *, um sie alle auf einmal zu aktivieren. Beim erneuten Laden der Konfiguration ist ein Fehler aufgetreten. Nach dem Neustart von Apache wurde in der Datei error.log die folgende Fehlermeldung angezeigt:

Hoppla, für 'server.host.name:0' wurde kein RSA- oder DSA-Serverzertifikat gefunden ?!

Die meisten Ergebnisse für diese Fehlermeldung sind Jahre alt, die das Problem nicht beheben, oder es handelt sich um Fehler, die unter https://issues.apache.org/bugzilla/show_bug.cgi?id=31709 behoben wurden

Von: http://www.clearchain.com/blog/posts/solving-the-apache-ssl-error-oops-no-rsa-or-dsa-server-certificate-found-for-www-somedomain-com0

Zusammenfassung: Dieser Fehler kann auch auftreten, wenn Sie die folgende Zeile in Ihrem VirtualHostAbschnitt vergessen haben :

SSLEngine on

Das Problem trat in einer anderen Konfigurationsdatei auf als der im Fehler aufgeführte Host. Dies lag an der Tatsache, dass zwei der Dateien doppelte ServerName-Werte enthielten. Ich habe das falsche Problem behoben und es hat wieder angefangen (tschüss, diese halbe Stunde) :-).

Um dies zu beheben, habe ich alle Websites deaktiviert und dann ein paar gleichzeitig aktiviert, bis ich erneut auf das Problem gestoßen bin.

Möglicherweise wird dieser Fehler auch angezeigt, wenn Sie ein Zertifikat mit mehreren alternativen Antragstellernamen verwenden, die ServerNameDirektive jedoch nicht mit den CN- oder SAN-Werten des Zertifikats übereinstimmt. IT ist häufig der Fall, wenn ein Entwickler eine Entwicklungsversion desselben Produktionsstandorts haben möchte, für den Entwicklungsstandort jedoch kein echtes Zertifikat vorhanden ist.

Beispiel-Websites:
webserver.example.com
webserver-dev.example.com

Zertifikat:
CN = primaryserver.example.com
SANs = webserver.example.com, puppies.example.com, kittens.example.com

Die folgende Konfiguration verursacht diesen Fehler:
/etc/apache2/sites-enabled/webserver.example.com-ssl.conf
<IfModule mod_ssl.c> <VirtualHost *:443> ServerName webserver.example.com ...
/etc/apache2/sites-enabled/webserver-dev.example.com-ssl.conf
<IfModule mod_ssl.c> <VirtualHost *:443> ServerName webserver-dev.example.com ...

Die folgende Konfiguration behebt das Problem:
/etc/apache2/sites-enabled/webserver.example.com-ssl.conf
<IfModule mod_ssl.c> <VirtualHost *:443> ServerName webserver.example.com ...
/etc/apache2/sites-enabled/webserver.example.com-ssl.conf
<IfModule mod_ssl.c> <VirtualHost webserver-dev.example.com:443> ServerName webserver.example.com ...

FWIW, ich bin gerade unter einem anderen Deckmantel erneut auf dieses Thema gestoßen.

Wenn Sie Wildcard-SSL-Zertifikate verwenden, stellen Sie sicher, dass der VirtualHost-Eintrag für die Domain (domain.com) vor allen anderen Einträgen (foo.domain.com, bar.domain.com usw.) aufgeführt ist.

Ich habe die Konfigurationssache nacheinander ausprobiert, und alles andere lief gut, bis ich diese eine Datei wieder hinzufügte.

Dann stellte ich fest, dass der Konfigurationsdateiname alphabetisch niedriger war als die Konfigurationsdatei mit der "primären Domänendefinition". Der Symlink wurde so geändert, dass er nach dem Hauptdef platziert wurde und alles wie ein Zauber funktionierte.

Beispiel für eine fehlgeschlagene Auflistung:

foo.domain.conf
prim.domain.conf
something.domain.conf

Arbeitsbeispiel Auflistung:

prim.domain.conf
something.domain.conf
zfoo.domain.conf

HTH jemand anderes :)