misterunknown: SSL-Protocol Error mit POP3

Moin,

ich wollte gerade versuchen die Mails von meinem Server (dovecot/postfix) per POP3 abzuholen, genauer gesagt, das Konto bei Gmail hinzufügen.

Leider war mir das nicht möglich, da es ein Problem mit der Verschlüsselung gibt. Ich konnte 2 Fehler generieren:
  - ohne SSL: Fehlermeldung: Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
  - mit SSL: SSL protocol error. Please try disabling SSL, or contact your other provider to verify the correct port settings.

Die Porteinstellungen waren richtig. Meines Erachtens sind auch die SSL-Einstellungen am Server richtig. Meine Vermutung ist, dass Google das SSL-Zertifikat des Servers nicht akzeptiert. Liege ich damit richtig? Wenn ja, wie kann ich dieses Poblem beheben?

Ich habe das Zertifikat nicht selbst generiert, sondern bei der Installation des Servers wurde das automatisch mit erstellt. Ich bin mir ziemlich sicher, dass das auch über openssl req ... gemacht wurde. Es würde also nichts bringen, einfach ein neues mit openssl zu erstellen, oder?

Grüße Marco

  1. Tach,

    wenn du deine Mailserverfragen in einem Thread behieltest, würde ich wahrscheinlicher keine davon verpassen.

    Ich habe das Zertifikat nicht selbst generiert, sondern bei der Installation des Servers wurde das automatisch mit erstellt. Ich bin mir ziemlich sicher, dass das auch über openssl req ... gemacht wurde. Es würde also nichts bringen, einfach ein neues mit openssl zu erstellen, oder?

    Richtig, Zertifikate, so wie wir sie nutzen, sind nur mit Vertrauen vernünftig nutzbar: Da du das Zertifikat selber ausgestellt hast und vermutlich damit nicht persönlich zu Google gefahren bist, um ihnen zu beweisen, dass das dein Zertifikat ist, können sie dem nicht trauen. Alternativ kannst du dir dein Zertifikat von einer (mutmaßlich) vertrauenswürdigen Dritten unterschreiben lassen, der Google vertraut, dass sie weiß, was sie tut. Das muss nix kosten, z.B. bei https://www.startssl.com/. Wenn du alles richtig konfiguriert hast, sollte sich z.B. auch dein Thunderbird nicht mehr über das Zertifikat beschweren.

    mfg
    Woodfighter

    P.S. Generisches Feminum, andersgeschlechtliche Zertifizierinnen sind mitgemeint.

    1. Moin,

      wenn du deine Mailserverfragen in einem Thread behieltest, würde ich wahrscheinlicher keine davon verpassen.

      Das wäre mir recht :) Ich dachte nur, da es hier ja eher ein SSL-Problem ist, gehört das nicht in den anderen Thread.

      Das muss nix kosten, z.B. bei https://www.startssl.com/. Wenn du alles richtig konfiguriert hast, sollte sich z.B. auch dein Thunderbird nicht mehr über das Zertifikat beschweren.

      Das ist sehr geil. Wenn man sich die Kosten für SSL-Zertifikate anderer Anbieter anschaut fällt man direkt ins Delirium furibundum sive furiosum^^

      Ich habe mich da angemeldet. Da stellt sich mir aber gleich die nächste Frage. Man hat dort einen "Validations Wizard" (ich liebe ja Wizards, die sind so väterlich anleitend), allerdings weiß ich nicht, ob ich jetzt meine Email-Adresse validieren soll, oder meinen Domainname. Theoretisch ja den Domainname, da die Domain ja das Zertifikat bereitstellen soll, und das sicherlich nicht für jeden Benutzer einzeln. Da frage ich mich aber, wozu es dann überhaupt die Email-Adress-Validation gibt!? Oder muss ich doch für jeden Benutzer ein eigenes Zertifikat erstellen?

      Grüße Marco

      1. Tach,

        Ich habe mich da angemeldet. Da stellt sich mir aber gleich die nächste Frage. Man hat dort einen "Validations Wizard" (ich liebe ja Wizards, die sind so väterlich anleitend), allerdings weiß ich nicht, ob ich jetzt meine Email-Adresse validieren soll, oder meinen Domainname. Theoretisch ja den Domainname, da die Domain ja das Zertifikat bereitstellen soll, und das sicherlich nicht für jeden Benutzer einzeln. Da frage ich mich aber, wozu es dann überhaupt die Email-Adress-Validation gibt!? Oder muss ich doch für jeden Benutzer ein eigenes Zertifikat erstellen?

        beim Validieren der Domain, wird überprüft, ob du ausreichende Herrschaft über die Domain hast, d.h. Mails an eine der beim Domain-Registrar angegebenen E-Mail-Adressen oder eine der typischen wie hostmaster@, postmaster@ oder webmaster@ hast und du erhälst dann ein Zertifikat für diese Domain. Bei der E-Mail-Adress-Validation darfst du dir aussuchen, wie die Adresse ist, du erhälst dann allerdings nur ein Zertifikat für diese Adresse und nicht die Domain, z.B. zum Nutzen mit GPG.

        mfg
        Woodfighter

        1. Moin,

          beim Validieren der Domain, wird überprüft, ob du ausreichende Herrschaft über die Domain hast, d.h. Mails an eine der beim Domain-Registrar angegebenen E-Mail-Adressen oder eine der typischen wie hostmaster@, postmaster@ oder webmaster@ hast und du erhälst dann ein Zertifikat für diese Domain.

          Ich habe das Zertifikat erhalten. Der Apache nimmt das auch, das habe ich probiert. Also es sei denn du musst mich eines besseren belehren: https://themisterunknown.de.

          Der Dovecot will das nicht so richtig. Aus der config:

          # Some general options  
          protocols = imap pop3 sieve  
          disable_plaintext_auth = yes  
          ssl = yes  
          ssl_cert = </etc/ssl/certs/dovecot.pem  
          ssl_key = </etc/ssl/private/dovecot_key.pem  
          ssl_cipher_list = ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH+MEDIUM  
          ssl_ca = </etc/apace2/ssl/ca.pem  
            
          #ssl_cert = </etc/ssl/certs/ssl-mail.pem  
          #ssl_key = </etc/ssl/private/ssl-mail.key  
          #ssl_cipher_list = ALL:!LOW:!SSLv2:ALL:!aNULL:!ADH:!eNULL:!EXP:RC4+RSA:+HIGH:+MED  
          IUM
          

          Die auskommentierten Zeilen sind standardmäßig aktiviert gewesen. Damit startet der Dovecot ohne Probleme. Die oberen aktiven Zeilen habe ich hinzugefügt. Wenn ich diese Konfiguration speichere und den Dienst neu starte kriege ich zwar keine Fehlermeldung, aber der Dienst läuft trotzdem nicht, oder nur Sekunden. Das weiß ich, weil einerseits der Port nicht gebunden wird, andererseits taucht der Dovecot nicht in der Prozessliste auf.

          Ich habe mich an diesen Artikel gehalten. Die ssl_cipher_list ist analog zur SSLCipherSuite des Apache.

          Bei der E-Mail-Adress-Validation darfst du dir aussuchen, wie die Adresse ist, du erhälst dann allerdings nur ein Zertifikat für diese Adresse und nicht die Domain, z.B. zum Nutzen mit GPG.

          Das wäre also beispielsweise etwas für meine Gmail-Adresse, wenn ich GPG nutzen will.

          Grüße Marco

          1. Tach,

            Ich habe das Zertifikat erhalten. Der Apache nimmt das auch, das habe ich probiert. Also es sei denn du musst mich eines besseren belehren: https://themisterunknown.de.

            Sieht gut aus; ich persönlich würde das Ajaxterm übrigens noch hinter einer Basic Auth „verstecken“, weil ich dem nicht so ganz traue.

            Die auskommentierten Zeilen sind standardmäßig aktiviert gewesen. Damit startet der Dovecot ohne Probleme. Die oberen aktiven Zeilen habe ich hinzugefügt. Wenn ich diese Konfiguration speichere und den Dienst neu starte kriege ich zwar keine Fehlermeldung, aber der Dienst läuft trotzdem nicht, oder nur Sekunden. Das weiß ich, weil einerseits der Port nicht gebunden wird, andererseits taucht der Dovecot nicht in der Prozessliste auf.

            Was steht denn im Log?

            Ich habe mich an diesen Artikel gehalten.

            Sieht eigentlich erstmal gut aus, wenn du die Pfade deinen Begebenheiten angepasst hattest.

            Die ssl_cipher_list ist analog zur SSLCipherSuite des Apache.

            Die würde ich erstmal auf dem dovecot-Standard lassen.

            Bei der E-Mail-Adress-Validation darfst du dir aussuchen, wie die Adresse ist, du erhälst dann allerdings nur ein Zertifikat für diese Adresse und nicht die Domain, z.B. zum Nutzen mit GPG.

            Das wäre also beispielsweise etwas für meine Gmail-Adresse, wenn ich GPG nutzen will.

            oder für deine @themisterunknown.de-Adressen…

            mfg
            Woodfighter

            1. Moin,

              Sieht gut aus; ich persönlich würde das Ajaxterm übrigens noch hinter einer Basic Auth „verstecken“, weil ich dem nicht so ganz traue.

              Holla. Theoretisch solltest du (mittlerweile?) auf die normale Hauptseite kommen, das Ajaxterm habe ich eigentlich hinter einer Sumdomain laufen. Aber stimmt, Basic Auth sollte da möglich sein. Ich hatte erst einen Fehler gekriegt, weil ich die Direktiven mit in den VirtualHost-Kontext geschrieben hatte, aber die gehören ja in einen Directory-Kontext. Das mach ich gleich mal.

              Was steht denn im Log?

              Hm. Ich habe gerade mal in die /var/log/mail.log geschaut. Die letzten Einträge sind folgende:

              Jan 31 11:14:38 themisterunknown dovecot: anvil: Warning: Killed with signal 15  
              (by pid=1 uid=0 code=kill)  
              Jan 31 11:14:38 themisterunknown dovecot: log: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)  
              Jan 31 11:14:38 themisterunknown dovecot: master: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)  
              Jan 31 11:46:37 themisterunknown dovecot: master: Dovecot v2.0.19 starting up (core dumps disabled)  
              Jan 31 11:47:30 themisterunknown dovecot: log: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)  
              Jan 31 11:47:30 themisterunknown dovecot: master: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)  
              Jan 31 14:40:35 themisterunknown dovecot: master: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)  
              Jan 31 14:40:35 themisterunknown dovecot: log: Warning: Killed with signal 15 (by pid=1 uid=0 code=kill)
              

              An den Stellen, an denen kein Abbruch kam, hatte ich die alten Werte wieder aktiviert. Wenn ich mich an die Kill-Signale richtig erinnere, ist 15 ja "graceful terminating" oder sowas... Die Frage ist: Wer macht das und warum? uid=0 sollte der root sein, pid=1 ist bei mir der init-Prozess (/sbin/init). Bleibt die Frage warum...

              Sieht eigentlich erstmal gut aus, wenn du die Pfade deinen Begebenheiten angepasst hattest.

              Habe ich.

              Die würde ich erstmal auf dem dovecot-Standard lassen.

              Meinst du? Was genau macht die eigentlich? In diese Richtung habe ich nichts wirklich erleuchtendes gefunden.

              Das wäre also beispielsweise etwas für meine Gmail-Adresse, wenn ich GPG nutzen will.
              oder für deine @themisterunknown.de-Adressen…

              Richtig. Vielleicht richte ich mir eine sichere Mailadresse ein, aber ich hab gehört, dass viele Emaildienste kein GPG unterstützten, zumindest nicht die gängigen Webmail-Dienste.

              Grüße Marco

              1. Tach,

                Holla. Theoretisch solltest du (mittlerweile?) auf die normale Hauptseite kommen, das Ajaxterm habe ich eigentlich hinter einer Sumdomain laufen.

                kam man auch, ich war nur neugierig.

                Was steht denn im Log?

                Hm. Ich habe gerade mal in die /var/log/mail.log geschaut. Die letzten Einträge sind folgende:

                Bin mir gerade nicht ganz sicher, da ich hier kein dovecot habe, aber was sagen /var/log/mail.err /var/log/syslog? Ist das Logging von dovecot auf einen entsprechend niedrigen Wert eingestellt?

                uid=0 sollte der root sein, pid=1 ist bei mir der init-Prozess (/sbin/init). Bleibt die Frage warum...

                User 0 ist immer root, egal wie er heißen mag und Prozess 1 ist immer init, solange es ein init-basiertes System ist.

                Meinst du? Was genau macht die eigentlich? In diese Richtung habe ich nichts wirklich erleuchtendes gefunden.

                Das gibt an, welche Verschlüsselungen tatsächlich benutzt werden dürfen und welche nicht; SSL ist quasi ein Sammelsurium an verschiedenen Verschlüsselungstechniken und die Dienste definieren jeweils, mit was die Clients ankommen dürfen: http://www.skytale.net/blog/archives/22-SSL-cipher-setting.html

                Richtig. Vielleicht richte ich mir eine sichere Mailadresse ein, aber ich hab gehört, dass viele Emaildienste kein GPG unterstützten, zumindest nicht die gängigen Webmail-Dienste.

                Das macht ja nix, und es ist ja nichts, was dauerhaft an der Mailadresse hängt, sondern für jede Mail einzeln entschieden werden kann.

                mfg
                Woodfighter

                1. Moin,

                  kam man auch, ich war nur neugierig.

                  Ah ok :) Schlingel. Einfach per Basic Auth schützen lässt sich das allerdings nich :( Das Ding läuft als Dienst lokal unter http://localhost:8022/. Der entsprechende Apache-Eintrag ist nur ein Proxyverweis darauf. Selbs wenn ich also einem Directory-Kontext den Ordner /usr/share/ajaxterm schütze, passiert nichts. Klingt komisch, ist aber so...

                  Bin mir gerade nicht ganz sicher, da ich hier kein dovecot habe, aber was sagen /var/log/mail.err /var/log/syslog? Ist das Logging von dovecot auf einen entsprechend niedrigen Wert eingestellt?

                  Ich hab den Fehler gefunden. Er lag in der Buchstabierung einer der Dateinamen :) Jetzt rennt der Dovecot wenigstens. Gmail als auch K9Mail können trotzdem keine Mails holen. Fehler bei Gmail: Contact your other Email-Provider. Ich bin schon in mich gegangen, kam aber nichts bei raus :-P
                  Fehler bei K9Mail: SSl handshake aborted: ssl=0x5c32fff8: I/O error during system call, Connection reset by peer)

                  Damit kann ich grade auch nichts anfangen.

                  uid=0 sollte der root sein, pid=1 ist bei mir der init-Prozess (/sbin/init). Bleibt die Frage warum...

                  Diese Frage stellt sich mir aber immer noch. Nur, weil ich einen Dateinamen falsch geschrieben hat, wird der Dovecot vom Init-Prozess gekillt? Woher weiß der das denn? Und wieso wird das nicht geloggt? Naja, ich geh erstmal heim, ein Bierchen trinken.

                  Das gibt an, welche Verschlüsselungen tatsächlich benutzt werden dürfen und welche nicht; SSL ist quasi ein Sammelsurium an verschiedenen Verschlüsselungstechniken und die Dienste definieren jeweils, mit was die Clients ankommen dürfen: http://www.skytale.net/blog/archives/22-SSL-cipher-setting.html

                  Danke für den Link, ich les mir das morgen durch.

                  Schönen Abend dir erstmal noch :)

                  Grüße Marco

                  1. Tach,

                    Ah ok :) Schlingel.

                    die Information hast du geleakt, als Admin ist es durchaus wichtig, wo sich eventuelle Sidechannels existieren. Hast du denn 'ne Idee wie ich die andere Domain gefunden habe?

                    Einfach per Basic Auth schützen lässt sich das allerdings nich :( Das Ding läuft als Dienst lokal unter http://localhost:8022/. Der entsprechende Apache-Eintrag ist nur ein Proxyverweis darauf. Selbs wenn ich also einem Directory-Kontext den Ordner /usr/share/ajaxterm schütze, passiert nichts. Klingt komisch, ist aber so...

                    natürlich nicht, ich wollte nur sehen, ob du selber drauf kommst: „Be careful with the directory-path arguments: They have to literally match the filesystem path which Apache uses to access the files.“ - Apache greift aber gar nicht auf die Dateien zu; du möchtest eine Location-Directive.

                    Ich hab den Fehler gefunden. Er lag in der Buchstabierung einer der Dateinamen :)

                    Aus Erfahrung, niemals tippen, immer copy und paste benutzen, wozu hat man eine mittlere Maustaste.

                    Jetzt rennt der Dovecot wenigstens. Gmail als auch K9Mail können trotzdem keine Mails holen. Fehler bei Gmail: Contact your other Email-Provider. Ich bin schon in mich gegangen, kam aber nichts bei raus :-P
                    Fehler bei K9Mail: SSl handshake aborted: ssl=0x5c32fff8: I/O error during system call, Connection reset by peer)

                    Damit kann ich grade auch nichts anfangen.

                    Der Server möchte aber kein SSL (aber auch kein IMAP) mit mir reden, auch wenn der Port offen ist:

                    woodfighter@woodfighter:~$ openssl s_client -showcerts -connect  mail.themisterunknown.de:993 </dev/null
                    CONNECTED(00000003)
                    write:errno=104

                    104 bedeutet quasi connection reseet by peer

                    Und wieso wird das nicht geloggt?

                    Weil du es so konfiguriert hast. In welche Logs hast du geschaut, wie ist das Logging von dovecot eingestellt?

                    Bleibt die Frage warum...

                    Du hast init darum gebeten den Prozess für dich zu starten, das schlägt fehl und landet dann entsprechend im Log.

                    mfg
                    Woodfighter

                    1. Moin,

                      die Information hast du geleakt, als Admin ist es durchaus wichtig, wo sich eventuelle Sidechannels existieren. Hast du denn 'ne Idee wie ich die andere Domain gefunden habe?

                      In der httpd.conf aus dem Post mit den name-based virtual SSL-Hosts nehme ich an :)

                      natürlich nicht, ich wollte nur sehen, ob du selber drauf kommst: „Be careful with the directory-path arguments: They have to literally match the filesystem path which Apache uses to access the files.“ - Apache greift aber gar nicht auf die Dateien zu; du möchtest eine Location-Directive.

                      Hm. Ich habe jetzt folgende 2 Varianten in der httpd.conf probiert:

                      <Location http://localhost:8022/>  
                      AuthType Basic  
                      AuthName "Admin access - only valid users"  
                      AuthUserFile /var/www/.htpasswd  
                      </Location>
                      

                      und dann mit

                      <Location https://ssh.themisterunknown.de/>  
                      ...
                      

                      Neustart Apache ging problemlos. Bewirkt hat weder das eine, noch das andere etwas.

                      Aus Erfahrung, niemals tippen, immer copy und paste benutzen, wozu hat man eine mittlere Maustaste.

                      Hätte ich liebend gern gemacht, aber da unser Proxy außer http nichts durchlässt und der lokale Virenscanner httptunnel als böses Teufelswerk ansieht, bin ich auf Ajaxterm angewiesen; womit Copy&Paste (auch mit entsprechendem Plugin für Javascript-Zugriff aufs Clipboard) nicht funktioniert. Keine Ahnung warum.

                      Der Server möchte aber kein SSL (aber auch kein IMAP) mit mir reden, auch wenn der Port offen ist:
                      woodfighter@woodfighter:~$ openssl s_client -showcerts -connect  mail.themisterunknown.de:993 </dev/null
                      CONNECTED(00000003)
                      write:errno=104
                      104 bedeutet quasi connection reseet by peer

                      Hm. Also einerseits weiß ich nicht, ob mail.themisterunknown.de korrekt ist. Der A-Record leitet meines wissens alles auf themisterunknown.de um und nur der Apache ermöglicht VirtualHosts. Wie das mit dem MX-Record ist, weiß ich nicht genau (ich wusste bis vor kurzem nicht mal, was das eigentlich ist). Ich glaube aber auch, dass er auf themisterunknown.de zeigt. Ob man nun mail.themisterunknown.de nimmt, oder themisterunknown.de ist entweder egal, oder mail.themisterunknown.de ist falsch. Ich tippe aus dem Bauch heraus auf "egal".

                      Was allerdings nicht mein Problem beseitigt, dass irgendwo der Wurm drin ist. Bis auf die SSL_*-Direktiven habe ich nichts geändert; ohne diese ging es aber. Also steht dort noch die Kuh im Pfeffer begraben.

                      Weil du es so konfiguriert hast. In welche Logs hast du geschaut, wie ist das Logging von dovecot eingestellt?

                      Tja, wer weiß das schon xD In der entsprechenden conf-Datei (10-logging.conf in /etc/dovecot/conf.d) steht nur log_path = syslog. Die Doku sagt, dass dann über den syslog-Dienst eingestellt wird, wie verfahren wird. Dort wiederum habe ich gelesen, dass standardmäßig die /var/log/mail*-Dateien verwendet werden. Da die mail.err* leer sind, bleiben noch die /var/log/mail.log*-Dateien. Dort steht folgendes:

                      Feb  1 03:27:23 themisterunknown postfix/anvil[20805]: statistics: max connection rate 1/60s for (smtp:123.232.112.194) at Feb  1 03:24:03  
                      Feb  1 03:27:23 themisterunknown postfix/anvil[20805]: statistics: max connection count 1 for (smtp:123.232.112.194) at Feb  1 03:24:03  
                      Feb  1 03:27:23 themisterunknown postfix/anvil[20805]: statistics: max cache size 1 at Feb  1 03:24:03  
                      Feb  1 04:59:38 themisterunknown dovecot: pop3-login: Fatal: Can't load ssl_cert: error:0906D066:PEM routines:PEM_read_bio:bad end line  
                      Feb  1 04:59:38 themisterunknown dovecot: master: Error: service(pop3-login): command startup failed, throttling
                      

                      Irgendetwas scheint also mit dem SSL-Cert nicht zu stimmen. Aber das habe ich ja nicht selbst erstellt, weiß auch nicht, welches Zeichen am Ende erwartet wird. Problem könnte allerdings sein, dass ich ja 2 Zertifikate ineinander gehauen habe... wie eben hier beschrieben. Aber wie sonst sollte ich das machen?

                      Du hast init darum gebeten den Prozess für dich zu starten, das schlägt fehl und landet dann entsprechend im Log.

                      Hm. Schade, dass der Dovecot nicht so clever ist, und ins Log schreibt, dass er einen fehlerhaften Eintrag in der Config-Datei hat. Oder sogar die Direktive... Naja. Rennen tut er momentan.

                      Grüße Marco

                      1. Tach!

                        Nur drei Punkte, weil ich die Diskussion nicht mit der nötigen Aufmerksamkeit verfolge:

                        Hm. Ich habe jetzt folgende 2 Varianten in der httpd.conf probiert:
                        [code lang=conf]<Location http://localhost:8022/>
                        [code lang=conf]<Location https://ssh.themisterunknown.de/>
                        Neustart Apache ging problemlos. Bewirkt hat weder das eine, noch das andere etwas.

                        Die Code-Auszeichnung für Apache-Direktiven ist "apache", nicht "conf".

                        Du solltest das Apache-Handbuch zu Rate ziehen und nicht raten, wenn du was neues verwendest. Dort steht ziemlich deutlich, was Location in welcher Situation für einen Wert erwartet.

                        [Records] Ich glaube aber auch, dass er auf themisterunknown.de zeigt.

                        Glauben bringt dich nicht wirklich weiter. nslookup heißt das Werkzeug zum nachsehen. Gibts auch als Online-Variante. nslookup zeigt aber erstmal nur den A-Record an. Nimm dann noch -query=mx als Parameter.

                        dedlfix.

                        1. Moin,

                          Die Code-Auszeichnung für Apache-Direktiven ist "apache", nicht "conf".

                          Das wusste ich nicht. Ich habe mir nur damit beholfen. Gibt es auch noch andere Auszeichnungen, die nicht aufgeführt sind?

                          Du solltest das Apache-Handbuch zu Rate ziehen und nicht raten, wenn du was neues verwendest. Dort steht ziemlich deutlich, was Location in welcher Situation für einen Wert erwartet.

                          Ja, ich weiß.
                          "Für Proxy-Anfragen hat die Vergleichs-URL die Form schema://servername/path. Das Präfix muss angegeben werden." (Apache Doku)
                          Was ich nicht weiß, ist was genau mit "schema" und "servername" gemeint ist. Meine beiden Vermutungen brachten nichts.

                          Glauben bringt dich nicht wirklich weiter. nslookup heißt das Werkzeug zum nachsehen. Gibts auch als Online-Variante. nslookup zeigt aber erstmal nur den A-Record an. Nimm dann noch -query=mx als Parameter.

                          Hm. Das zeigt auf mail.themisterunknown.de. Trotzdem wird im Endeffekt ja meine IP angesprochen. Also ist es egal, ob man themisterunknown.de oder mail.themisterunknown.de angibt. Was sich auch nachvollziehen lässt, da ich in Roundcube als Servername immer themisterunknown.de angegeben habe und es funktionierte (bevor ich die SSL-Probleme verursachte).

                          Grüße Marco

                          1. Tach,

                            Die Code-Auszeichnung für Apache-Direktiven ist "apache", nicht "conf".

                            Das wusste ich nicht. Ich habe mir nur damit beholfen. Gibt es auch noch andere Auszeichnungen, die nicht aufgeführt sind?

                            http://forum.de.selfhtml.org/hilfe/bedienung.htm#syntax-highlighting

                            Du solltest das Apache-Handbuch zu Rate ziehen und nicht raten, wenn du was neues verwendest. Dort steht ziemlich deutlich, was Location in welcher Situation für einen Wert erwartet.

                            Ja, ich weiß.
                            "Für Proxy-Anfragen hat die Vergleichs-URL die Form schema://servername/path. Das Präfix muss angegeben werden." (Apache Doku)

                            Okay, das ist missverständlich, mit Proxy-Anfragen sind nur Forward-Proxy-Anfragen gemeint, nicht Reverse-Proxy-Anfragen; du hast einen Origin-Request; bitte gewöhne dir an die englische Doku zu verwenden, die ist erfahrungsgemäß meist aktueller und besser gepflegt.

                            Was ich nicht weiß, ist was genau mit "schema" und "servername" gemeint ist. Meine beiden Vermutungen brachten nichts.

                            Du bist root, finde es heraus (des Admins Leben besteht erstmal aus sehr viel Lesen, bevor man die Füße hochlegen kann): https://tools.ietf.org/html/rfc3986

                            mfg
                            Woodfighter

                            1. Moin,

                              Was ich nicht weiß, ist was genau mit "schema" und "servername" gemeint ist. Meine beiden Vermutungen brachten nichts.
                              Du bist root, finde es heraus (des Admins Leben besteht erstmal aus sehr viel Lesen, bevor man die Füße hochlegen kann): https://tools.ietf.org/html/rfc3986

                              Was scheme und servername gemeint ist, weiß ich eigentlich schon. Nur was ich angeben solle war mir unklar. Allerdings ist mir beim durchstöbern der Doku noch ein Fehler von mir aufgefallen, und zwar habe ich die Location-Direktive nicht in den VirtualHost-Kontext gepackt. Das ist jetzt geändert. Aber die Authentifikation funktioniert trotzdem nicht. Die httpd.conf sieht jetzt so aus (Auszug):

                              <VirtualHost *:443>  
                                      ServerName ssh.themisterunknown.de  
                                      SSLEngine On  
                                      SSLProtocol all -SSLv2  
                                      SSLCertificateFile /etc/apache2/ssl/realssl.crt  
                                      SSLCertificateKeyFile /etc/apache2/ssl/realssl.key  
                                      SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM  
                                      SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem  
                                      SSLCACertificateFile /etc/apache2/ssl/ca.pem  
                                      ProxyRequests Off  
                                      <Proxy *>  
                                              Order deny,allow  
                                              Allow from all  
                                      </Proxy>  
                                      ProxyPass / http://localhost:8022/  
                                      ProxyPassReverse / http://localhost:8022/  
                                      <Location http://localhost:8022/>  
                                              AuthType Basic  
                                              AuthName "Admin access - valid users only"  
                                              AuthUserFile /var/www/.htpasswd  
                                      </Location>  
                              </VirtualHost>
                              

                              Da du Origin Requst (keine Ahnung was das ist :)) gesagt hast, hatte ich auch testweise <Location /> probiert, auch kein Ergebnis. Ich bin nie nach Benutzerdaten in der /var/www/.htpasswd gefragt worden...

                              Grüße Marco

                              1. Tach,

                                Da du Origin Requst (keine Ahnung was das ist :)) gesagt hast, hatte ich auch testweise <Location /> probiert, auch kein Ergebnis. Ich bin nie nach Benutzerdaten in der /var/www/.htpasswd gefragt worden...

                                das war ein Zitat aus der englischen Apache Doku zur Location-Direktive, da steht dann auch direkt, was du falsch machst; u.a. den Apache interessiert nicht, wo das endgültige Ziel des Requests ist, sondern worauf der Client zuzugreifen versucht.

                                mfg
                                Woodfighter

                                1. Moin,

                                  den Apache interessiert nicht, wo das endgültige Ziel des Requests ist, sondern worauf der Client zuzugreifen versucht.

                                  Ja, das habe ich jetzt auch verstanden. Mein Problem war noch, dass die Require-Direktive gefehlt hat. Aber daraus lernt man nun.

                                  Ich danke euch beiden für eure Hilfe. Ihr seid Spitze.

                                  Grüße Marco

                          2. Tach!

                            "Für Proxy-Anfragen hat die Vergleichs-URL die Form schema://servername/path. Das Präfix muss angegeben werden." (Apache Doku)
                            Was ich nicht weiß, ist was genau mit "schema" und "servername" gemeint ist. Meine beiden Vermutungen brachten nichts.

                            Willst du denn hier mit dem Apachen einen Proxy aufbauen? Nein. Und schema://servername/path sollte dir von http://example.com/path bekannt sein.

                            dedlfix.

                            1. Moin,

                              Willst du denn hier mit dem Apachen einen Proxy aufbauen? Nein.

                              Doch. Denn das Ajaxterm, welches ich hier versuche zu sichern, wird nicht durch den Apache ausgeliefert, sondern läuft als eigener Dienst lokal auf dem Port 8022. Deshalb fungiert der Apache hier nur als Proxy auf den localhost.

                              Und schema://servername/path sollte dir von http://example.com/path bekannt sein.

                              Das dachte ich mir. Doch weder die Anwendung von http://localhost:8022/, noch von https://ssh.themisterunknown.de hat den gewünschten Effekt gebracht.

                              Grüße Marco

                              1. Tach!

                                Willst du denn hier mit dem Apachen einen Proxy aufbauen? Nein.
                                Doch. Denn das Ajaxterm, welches ich hier versuche zu sichern, wird nicht durch den Apache ausgeliefert, sondern läuft als eigener Dienst lokal auf dem Port 8022. Deshalb fungiert der Apache hier nur als Proxy auf den localhost.

                                Gut, aber dann willst du sicherlich den gesamten Proxy mit einer Passwortabfrage sichern und nicht nur bestimmte Ziele. Also brauchst du dafür auch kein <Location> sondern musst die Auth-Geschichte direkt im VHost einbauen.

                                dedlfix.

                                1. Moin,

                                  Gut, aber dann willst du sicherlich den gesamten Proxy mit einer Passwortabfrage sichern und nicht nur bestimmte Ziele. Also brauchst du dafür auch kein <Location> sondern musst die Auth-Geschichte direkt im VHost einbauen.

                                  Nein, da meckert unser Indianer rum. Auth-Direktiven sind im VirtualHost-Kontext nicht erlaubt.

                                  Grüße Marco

                                  1. Tach!

                                    Gut, aber dann willst du sicherlich den gesamten Proxy mit einer Passwortabfrage sichern und nicht nur bestimmte Ziele. Also brauchst du dafür auch kein <Location> sondern musst die Auth-Geschichte direkt im VHost einbauen.
                                    Nein, da meckert unser Indianer rum. Auth-Direktiven sind im VirtualHost-Kontext nicht erlaubt.

                                    Stimmt. Context Directory wird benötigt, also war Location doch notwendig, dann aber schlicht auf /

                                    dedlfix.

                                    1. Moin,

                                      Stimmt. Context Directory wird benötigt, also war Location doch notwendig, dann aber schlicht auf /

                                      Stimmt. Ich Horst habe jetzt auch alles richtig gemacht. Nur dummerweise hatte ich die Direktive "Require" vergessen, also wurde kein Passwort abgefragt -.-

                                      Jetzt funktioniert es aber. Zumindest bei mir. Bei dir hoffentlich auch? https://ssl.themisterunknown.de

                                      Grüße Marco

                                      1. Tach!

                                        Jetzt funktioniert es aber. Zumindest bei mir. Bei dir hoffentlich auch? https://ssl.themisterunknown.de

                                        Nur wenn ich die richtige Adresse nehme.

                                        dedlfix.

                                        1. Moin,

                                          Nur wenn ich die richtige Adresse nehme.

                                          Natürlich^^ So im Schreib-Wahn passiert das dummer Weise.

                                          Grüße Marco

                                          1. Tach!

                                            Nur wenn ich die richtige Adresse nehme.
                                            Natürlich^^ So im Schreib-Wahn passiert das dummer Weise.

                                            Falls du das noch nicht weißt, die erste VHost-Konfiguration, die der Apache zu einem NameVirtualHost finden kann, ist der Default-VHost (*:80 und *.443 bekommen jeweils ihren eigenen). Der bedient auch alle Hostnamen, die nicht explizit in einem ServerName oder ServerAlias angegeben sind. Da du anscheinend einen Catch-All-DNS-Eintrag hast, der sämtliche nicht extra konfigurierten DNS-Anfragen zu deiner (Haupt-)IP schickt, kommt man bei Vertippern immer auf diesen Default-VHost. Wenn das gewollt ist, dass man in einem solchen Fall immer auf deiner normalen Website landet, dann lass alles so, wie es ist. Ansonsten müsstest du dir für diesen Catch-All-Fall einen eigenen VHost erstellen und in der Konfiguration vor die anderen VHosts stellen.

                                            dedlfix.

                                            1. Moin,

                                              Wenn das gewollt ist, dass man in einem solchen Fall immer auf deiner normalen Website landet, dann lass alles so, wie es ist. Ansonsten müsstest du dir für diesen Catch-All-Fall einen eigenen VHost erstellen und in der Konfiguration vor die anderen VHosts stellen.

                                              Also ich habe das schon bemerkt, aber nicht wirklich intendiert. Wie würde denn die ServerName-Direktive für einen Catch-All-Fall aussehen? Einfach *.themisterunknown?

                                              Grundsätzlich würde ich lieber eine Fehlerseite für nicht existierende Subdomains zeigen.

                                              Grüße Marco

                                              1. Tach!

                                                Wie würde denn die ServerName-Direktive für einen Catch-All-Fall aussehen? Einfach *.themisterunknown?

                                                Der Default-VHost fängt alles, was zu keinem anderen ServerName/ServerAlias passt. Der braucht also im Prinzip gar keinen ServerName/ServerAlias-Eintrag.

                                                Wenn du ServerName *.example.com in den Default-VHost oder einen anderen weiter vorn liegenden schreibst, fängt der sämtliche Subdomains ab. Vhosts weiter hinten bekommen dann keinen Besuch mehr, auch wenn deren ServerName/-Alias zum angefragten Hostname passt.

                                                Grundsätzlich würde ich lieber eine Fehlerseite für nicht existierende Subdomains zeigen.

                                                Wenn du das dem DNS nicht abgewöhnen kannst, musst du den Default-VHost so umkonfigurieren, dass der nur Fehlerdokumente ausgibt.

                                                dedlfix.

                      2. Tach,

                        Moin,

                        die Information hast du geleakt, als Admin ist es durchaus wichtig, wo sich eventuelle Sidechannels existieren. Hast du denn 'ne Idee wie ich die andere Domain gefunden habe?

                        In der httpd.conf aus dem Post mit den name-based virtual SSL-Hosts nehme ich an :)

                        nö, wäre wohl einfacher gewesen; ich hatte die Information aus dem Zertifikat, dass https://themisterunknown.de schickt.

                        Hm. Also einerseits weiß ich nicht, ob mail.themisterunknown.de korrekt ist. Der A-Record leitet meines wissens alles auf themisterunknown.de um und nur der Apache ermöglicht VirtualHosts. Wie das mit dem MX-Record ist, weiß ich nicht genau (ich wusste bis vor kurzem nicht mal, was das eigentlich ist). Ich glaube aber auch, dass er auf themisterunknown.de zeigt. Ob man nun mail.themisterunknown.de nimmt, oder themisterunknown.de ist entweder egal, oder mail.themisterunknown.de ist falsch. Ich tippe aus dem Bauch heraus auf "egal".

                        Für dein IMAPS-Problem spielt der MX-Record keinerlei Rolle, der ist nur zum Mailversand da. In deinem Falle spielt es für IMAP auch tatsächlich keine Rolle ob themisterunknown.de oder mail.themisterunknown.de, da beide auf die selbe IP zeigen; für die Gültigkeit deines Zertifikats spielt der Hostname dann aber natürlich eine Rolle.

                        Tja, wer weiß das schon xD

                        Du bist root, du solltest das wissen, oder zumindest schnell nachschauen können.

                        Irgendetwas scheint also mit dem SSL-Cert nicht zu stimmen. Aber das habe ich ja nicht selbst erstellt, weiß auch nicht, welches Zeichen am Ende erwartet wird. Problem könnte allerdings sein, dass ich ja 2 Zertifikate ineinander gehauen habe... wie eben hier beschrieben. Aber wie sonst sollte ich das machen?

                        OK, der Fehler ist doch wenigstens mal eindeutig; deine Aufgabe jetzt: herausfinden, wie eine pem-Datei auszusehen hat und dafür sorgen, dass deine auch so aussieht; ich vermute mal es fehlt ein Zeilenumbruch.

                        Hm. Schade, dass der Dovecot nicht so clever ist, und ins Log schreibt, dass er einen fehlerhaften Eintrag in der Config-Datei hat. Oder sogar die Direktive... Naja. Rennen tut er momentan.

                        Wenn dir etwas am Logging-Verhalten nicht passt, dann ändere es: http://wiki2.dovecot.org/Logging#Dovecot_Logging — „There are several settings that control logging verbosity. By default they're all disabled, but they may be useful for debugging.“

                        mfg
                        Woodfighter

                        1. Moin,

                          Tja, wer weiß das schon xD
                          Du bist root, du solltest das wissen, oder zumindest schnell nachschauen können.

                          Die Einstellungen des Dovecot sind dahingehend recht allgemein. Der loggt stadardmäßig per syslog, und in der Syslog-Config sind dann die Mail-Logs angegeben. Dort stehen dann die korrekten Dateien drin. Kann man aber natürlich alles konfigurieren.

                          OK, der Fehler ist doch wenigstens mal eindeutig; deine Aufgabe jetzt: herausfinden, wie eine pem-Datei auszusehen hat und dafür sorgen, dass deine auch so aussieht; ich vermute mal es fehlt ein Zeilenumbruch.

                          Da hast du recht. Außerdem gab es noch das klitzekleine Problem, dass ich die SSL-Direktiven in /etc/dovecot/conf.d/01-mail... geschrieben habe, aber später noch eine Datei /etc/dovecot/conf.d/10-ssl.conf ausgewertet wurde, die mir meine Direktiven überschrieben hat. Darauf muss man aber erstmal kommen, wenn man die Datei nicht kennt und im Log nur steht, dass der Key nicht zum Cert passt, obwohl es exakt die gleichen Dateien sind, wie beim Apache, der sie hinnimmt.

                          Wenn dir etwas am Logging-Verhalten nicht passt, dann ändere es: http://wiki2.dovecot.org/Logging#Dovecot_Logging — „There are several settings that control logging verbosity. By default they're all disabled, but they may be useful for debugging.“

                          Ja, ich habe das Logging dahingehen angepasst, dass so viel wie möglich geloggt wird. Das werde ich jetzt, da es funktioniert wieder etwas zurücknehmen, ich will ja auch nicht, dass die vollaufenden Logs die Festplatte an die Grenze bringen. Aber es ist auch jeden Fall gut zu wissen, wie es im Zweifelsfall geht :)

                          Ich danke dir erstmal für deine Geduld diesbezüglich. War ne schwere Geburt^^

                          Grüße Marco

                          1. Tach,

                            Darauf muss man aber erstmal kommen, wenn man die Datei nicht kennt und im Log nur steht, dass der Key nicht zum Cert passt, obwohl es exakt die gleichen Dateien sind, wie beim Apache, der sie hinnimmt.

                            Man kann auch einfach nachsehen, wie die tatsächliche Konfiguration aussieht: http://wiki2.dovecot.org/Tools/Doveconf und bei der Fehlermeldung wäre für mich sofort klar gewesen, dass da vermutlich etwas anderes greift, als ich dachte, aber da ist vermutlich eine Erfahrungssache. Welche Konfiguration wohin gehört ist übrigens im Allgemeinen in /usr/share/doc/$paketname dokumentiert.

                            mfg
                            Woodfighter

                            1. Moin,

                              Man kann auch einfach nachsehen, wie die tatsächliche Konfiguration aussieht: http://wiki2.dovecot.org/Tools/Doveconf und bei der Fehlermeldung wäre für mich sofort klar gewesen, dass da vermutlich etwas anderes greift, als ich dachte, aber da ist vermutlich eine Erfahrungssache. Welche Konfiguration wohin gehört ist übrigens im Allgemeinen in /usr/share/doc/$paketname dokumentiert.

                              Ich habe jetzt die SSL-Direktiven auch in die 10-ssl.conf geschrieben. Dort gehören sie hin.

                              Grüße Marco