Httpd kann kein korrektes SSL verwenden

Ich habe eine von meiner Universität ausgestellte CA. Ich habe meine CSR mit ihrer öffentlichen Schlüsseldatei wie folgt generiert:

openssl genrsa -out myservername.key 2048 (new key)
openssl req -new -key myservername.key -out myservername.csr 

Ich habe ihnen die CSR geschickt, sie haben mir die signierte CRT-Datei zurückgeschickt.

Ich habe ein Verzeichnis für meine CA-Schlüssel und Zertifikate erstellt und dort abgelegt.

Der relevante Teil meiner httpd.conf sieht folgendermaßen aus:

<VirtualHost _default_:443>
SSLEngine on
SSLCACertificateFile /var/cosign/certs/CA/publickey.pem
SSLCertificateFile /var/cosign/certs/myserver.crt
SSLCertificateKeyFile /var/cosign/certs/myserver.key

DocumentRoot /var/www/html/
<Directory /var/www/html>
    Options -Indexes
    AllowOverride All
</Directory>

Dieses Zertifikat wird jedoch nicht für SSL verwendet. Wenn ich diesen Befehl mache:

openssl s_client -connect localhost:443 -showcerts

Ich verstehe das:

CONNECTED(00000003)
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = portcharlotte, emailAddress = root@portcharlotte
verify error:num=18:self signed certificate
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU =     SomeOrganizationalUnit, CN = portcharlotte, emailAddress = root@portcharlotte
verify return:1
---
Certificate chain

Mein CSR enthielt die richtigen Details, nicht diesen Unsinn von 'SomeState', 'SomeCity', von dem ich vermute, dass er ein Standard ist.

Das openssl-Modul wird installiert und geladen.

Die einzigen Fehler, die ich in Protokollen bekomme, sind:

[Fri Jan 25 13:27:40 2013] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Jan 25 13:27:40 2013] [warn] RSA server certificate CommonName (CN) `portcharlotte' does NOT match server name!?

Ich vermute, dass diese Nichtübereinstimmung darauf zurückzuführen ist, dass das falsche Zertifikat verwendet wird.

Meine Frage ist, wie kann ich es verwenden, um das richtige zu verwenden? Was vermisse ich?

SSLCACertificateFile /var/cosign/certs/CA/publickey.pem

Dies ist falsch, es sei denn, diese PEM-Datei enthält tatsächlich das CA-Zertifikat für die Client- Zertifikate, denen Sie Zugriff gewähren möchten. Verwenden Sie SSLCertificateChainFilestattdessen Apache, um eine Zertifikatkette bereitzustellen .

Apache muss über das tatsächliche Zertifikat und alle Zwischenzertifikate verfügen, die zum Signieren / Erstellen des Endpunktzertifikats verwendet werden, bis hin zu einem Stammzertifikat, dem Browser vertrauen.

Führen Sie Folgendes aus, um das Zertifikat zu überprüfen, das Sie erhalten haben:

openssl verify -CApath /path/to/CA/certs -purpose sslserver -verbose /your/certificate

Abgesehen von den Zertifikatproblemen fehlt Ihnen eine SSLRequireSSLDirektive in Ihrem vhost. Ohne diese Option sucht Apache nicht nach einer sicheren Verbindung.

Sie sollten auch nicht _default_als virtueller Host verwenden, und Ihnen fehlt ein ServerName.
Verwenden Sie entweder *: 443 oder IP: 443 als virtuellen Host.

Für jeden vhost muss ein gültiger Servername festgelegt sein, und außerdem muss ein SSL-vhost einen Servernamen haben, der dem CN des Zertifikats entspricht.

Zum Beispiel:

<VirtualHost 1.2.3.4:443>
  ServerName your.certificates.common.name
  ServerAlias any.subject.alternate.names

  DocumentRoot /your/protected/content

  SSLEngine On
  SSLCertificateChainFile /path/to/your/issuers/CA/cert/bundle

  SSLCertificateFile /path/to/your/certificate.crt
  SSLCertificateKeyfile /path/to/your/private.key
 -OR- 
  SSLCertificateFile /path/to/your/combined.cert-and-keyfile

  SSLRequireSSL

</VirtualHost>

Lesen Sie die Dokumentation ein wenig.

Lauf

# Debian/Ubuntu
apache2ctl -S
# RHEL/CentOS
httpd -S

Es sollte ungefähr so ​​etwas produzieren:

*:443                   is a NameVirtualHost
         default server hostname (/etc/apache2/sites-enabled/000-default:1)
         port 443 namevhost hostname (/etc/apache2/sites-enabled/000-default:1)

Stellen Sie sicher, dass Sie den Befehl openssl mit dem richtigen Hostnamen ausführen, um auf Ihren vhost zuzugreifen. Ich gehe davon aus, dass Sie mehrere vhosts für Port 443 haben und derjenige, der in der Standardeinstellung Ihrer Distribution definiert wurde, Vorrang hat.