Sicher in die Hölle

Posted on by

Für den Freifunk im Kreis GT soll es eine moderne Kommunikationsplattform geben. Der Teufel steckt mal wieder im Detail.

An sich läuft »Discourse«, eine moderne Forensoftware (mit einem latenten Hang zur Weltverbesserung) für den Gütersloher Freifunk schon. Nur beim Feature »Antworten per Mail«, da klemmte das auf Gleisen herumsausende Ruby-Machwerk: 

Job exception: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed

Die in Würde gealterte Serverschabe (deutsch für »Seasoned System Engineer«, was der Autor neuerdings öfter liest) erwartet aufgrund der Fehlermeldung eigentlich, daß das – aus Sicherheitsgründen auszumusternde – Protokoll SSLv3 vom POP3-Server nicht unterstützt würde. Aber, leider, weit gefehlt: 

wusel@ponder:~$ openssl s_client -ssl3 -connect mail.guetersloh.freifunk.net:995
CONNECTED(00000003)
depth=0 C = DE, ST = NRW, L = Guetersloh, O = Freifunk Guetersloh, OU = Network Services, CN = mail.guetersloh.freifunk.net, emailAddress = support@guetersloh.freifunk.net
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, ST = NRW, L = Guetersloh, O = Freifunk Guetersloh, OU = Network Services, CN = mail.guetersloh.freifunk.net, emailAddress = support@guetersloh.freifunk.net
verify return:1
---
Certificate chain
 0 s:/C=DE/ST=NRW/L=Guetersloh/O=Freifunk Guetersloh/OU=Network Services/CN=mail.guetersloh.freifunk.net/emailAddress=support@guetersloh.freifunk.net
   i:/C=DE/ST=NRW/L=Guetersloh/O=Freifunk Guetersloh/OU=Network Services/CN=mail.guetersloh.freifunk.net/emailAddress=support@guetersloh.freifunk.net
---
Server certificate
-----BEGIN CERTIFICATE-----
[…]
-----END CERTIFICATE-----
subject=/C=DE/ST=NRW/L=Guetersloh/O=Freifunk Guetersloh/OU=Network Services/CN=mail.guetersloh.freifunk.net/emailAddress=support@guetersloh.freifunk.net
issuer=/C=DE/ST=NRW/L=Guetersloh/O=Freifunk Guetersloh/OU=Network Services/CN=mail.guetersloh.freifunk.net/emailAddress=support@guetersloh.freifunk.net
---
No client certificate CA names sent
---
SSL handshake has read 1666 bytes and written 304 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 8FEE1591F3286FF8803ED22A9A1B3E514D1540016510E2C26C275710B51DE7BC
    Session-ID-ctx: 
    Master-Key: 2211C1847F33D64451E7BA4F2B36A3EF8567D687E49EB73BD461BCCFD8383E534B92DAABF17F61C9B3B58CADD7AA2828
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1461784212
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
---
+OK Dovecot ready.
quit
+OK Logging out
closed

Anders, als gedacht, wurde noch das self-signed Zertifikat benutzt, anstelle des vorhandenen Wildcard-Zertifikates, welches Freifunk Gütersloh über den Berliner Förderverein bekommen hat. Narf. Ove hatte das auch vor vielen Wochen mal moniert, aber, nunja, Zeit ist ein kostbares Gut, und ›never change a running system‹ …

Wie dem auch es, es wurde nun kurzerhand ein Let’s-Encrypt-Zertifikat installiert, damit liegt die Zertifizierungskiste wenigstens wieder völlig in unserer Hand: 

wusel@ponder:~$ openssl s_client -ssl3 -connect mail.guetersloh.freifunk.net:995
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=mail.guetersloh.freifunk.net
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
[…]
-----END CERTIFICATE-----
subject=/CN=mail.guetersloh.freifunk.net
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3554 bytes and written 304 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: 33648577DDBBA16BC70D6D02915FF5CCD66852F73CCEAFBF67E3C3EB558110EE
    Session-ID-ctx: 
    Master-Key: 2EF8486514FEE68CC81039D85AC1914A269003AD21D15AC73B0234640F310983FC2BDE1CCD3AC991EAD4917D27E07106
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1461793209
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
+OK Dovecot ready.
quit
+OK Logging out
closed

Und, schwupps, wurden auch die Mails von Discourse zu Postings verwandelt [1]. Narf. Einverstanden mit der generellen Nichtakzeptanz privater SSL-Zertifikate bin ich nach wie vor nicht; andererseits hat Let’s Encrypt jene mehr oder minder obsolet gemacht: ein »anerkanntes« Zertifikat kostet heute gerade mal ein »git clone« und 5 Minuten Zeitaufwand … Time well spent.

Ich verstünde jetzt noch gerne, warum es »verify error:num=20:unable to get local issuer certificate« heißt – und warum trotzdem der Zugriff funktioniert –, aber kommt Zeit, kommt auch diese Erkenntnis.

____
[1] Testpost

2 thoughts on “Sicher in die Hölle”

  1. “unable to get local issuer certificate”

    Ich verstehe davon ja nichts, aber vielleicht fehlt ihm ein Zertifikat aus der Kette, namentlich das Zwischenzertifikat? Dann hängt es davon ab, ob das gerade irgendwo gecached ist oder nicht.

    Das Problem hatte ich mit Apache 2.2; lässt man den die von letsencrypt bereitgestellten kombinierten Zertifikate (“fullchain”) ausliefern, tut das mit dem Browser nur intermittierend.

Comments are closed.