Hallo,
ich experimentiere gerade mit sebstgenerierten und selbstzertifizierten Schluesseln fuer Apache. Dabei ist mir eine Sache nicht klar: was muss ich als CN (common name) angeben? Moegliche Alternativen waeren da: a) die domain "*.example.com" b) der virtual hostname "www.example.com" c) der reverse resolved fqdn "server.example.com"
Die FAQ auf modssl.org (http://www.modssl.org/docs/2.8/ssl_faq.html#cert-real) empfiehlt b):
| Make sure you enter the FQDN ("Fully Qualified Domain Name") of the server | when OpenSSL prompts you for the "CommonName", i.e. when you generate a CSR | for a website which will be later accessed via https://www.foo.dom/, enter | "www.foo.dom" here.
Der Artikel "Introducing SSL and Certificates using SSLeay" vom Urspruenglichen Autor con modssl (http://www.pseudonym.org/ssl/wwwj-index.html) scheint anderer Meinung zu sein:
| As an example, a Netscape browser requires that the Common Name for a | certificate representing a server have a name which matches a regular | expression for the domain name of that server, such as *.pseudonym.org.
(Wobei der Autor seine ganz persoenliche Auffassung von Regular Expressions zu haben scheint.)
Wenn ich nun aber mein Zertifikat auf die FQDN des Virtual Hosts ausstelle, bekomme ich z.B. von sitecopy die Meldung
| Error: Server certificate verification failed: certificate issued for a | different hostname, issuer is not trusted
Kann mir jemand aus meiner Unwissenheit heraushelfen?
Thomas
Thomas Pircher schrieb:
Hallo,
ich experimentiere gerade mit sebstgenerierten und selbstzertifizierten Schluesseln fuer Apache. Dabei ist mir eine Sache nicht klar: was muss ich als CN (common name) angeben? Moegliche Alternativen waeren da: a) die domain "*.example.com" b) der virtual hostname "www.example.com" c) der reverse resolved fqdn "server.example.com"
Lösung B ist die richtige
[...]
Wenn ich nun aber mein Zertifikat auf die FQDN des Virtual Hosts ausstelle, bekomme ich z.B. von sitecopy die Meldung
Achtung bei mehreren Domains, auf einem einzigen Rechner mit nur einer IP. Ich habe haerausgefunden dass man pro IP nur 1 Zertifikat erstellen / laden kann.
| Error: Server certificate verification failed: certificate issued for a | different hostname, issuer is not trusted
Kann mir jemand aus meiner Unwissenheit heraushelfen?
Thomas
Hoffe es ist das was du gesucht hast.
Claudio
On Friday 09 December 2005 10:19, claudio.hofer@chofer.net wrote:
Thomas Pircher schrieb:
[common name (CN) in Zertifikaten] a) die domain "*.example.com" b) der virtual hostname "www.example.com" c) der reverse resolved fqdn "server.example.com"
Lösung B ist die richtige
Hallo Claudio, danke fuer die Antwort.
Achtung bei mehreren Domains, auf einem einzigen Rechner mit nur einer IP. Ich habe haerausgefunden dass man pro IP nur 1 Zertifikat erstellen / laden kann.
... was mich jetzt aber wieder stutzig macht. Also koennte doch c) die richtige Antwort sein? Wie hast du das herausgefunden? Apache macht keinen Mucks, nur sitecopy meckert 'rum.
Eigentlich koennte ich das alles so lassen, wie es ist, da es ja irgendwie funktioniert, nur packt mich der Ehrgeiz, es "richtig" zu machen...
Thomas
Thomas Pircher wrote:
On Friday 09 December 2005 10:19, claudio.hofer@chofer.net wrote: ... was mich jetzt aber wieder stutzig macht. Also koennte doch c) die richtige Antwort sein? Wie hast du das herausgefunden? Apache macht keinen Mucks, nur sitecopy meckert 'rum.
Eigentlich koennte ich das alles so lassen, wie es ist, da es ja irgendwie funktioniert, nur packt mich der Ehrgeiz, es "richtig" zu machen...
apache ist es egal was im cn steht, es geht um den client, der es verifizieren muss. dabei muss der cn mit dem hostname uebereinstimmen den du zum connecten verwendet hast. also nicht der fqdn des hosts, sondern wie claudio schon gesagt hat, der des virtualhosts.
schau dir mal www.cacert.org an, da kannst du dir auch richtige zertifikate ausstellen.
peter
On Friday 09 December 2005 13:58, Peter Warasin wrote:
apache ist es egal was im cn steht, es geht um den client, der es verifizieren muss. dabei muss der cn mit dem hostname uebereinstimmen den du zum connecten verwendet hast. also nicht der fqdn des hosts, sondern wie claudio schon gesagt hat, der des virtualhosts.
hmm, jetzt habe ich auch gefunden warum:
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html.en#vhosts
| Why can't I use SSL with name-based/non-IP-based virtual hosts? | | The reason is very technical, and a somewhat "chicken and egg" problem. The | SSL protocol layer stays below the HTTP protocol layer and encapsulates | HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to | negotiate the SSL protocol parameters with the client. For this, mod_ssl has | to consult the configuration of the virtual server (for instance it has to | look for the cipher suite, the server certificate, etc.). But in order to go | to the correct virtual server Apache has to know the Host HTTP header field. | To do this, the HTTP request header has to be read. This cannot be done | before the SSL handshake is finished, but the information is needed in order | to complete the SSL handshake phase. Bingo!
Danke fuer eure Antworten, Thomas