IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Encryption (Seite 7 von 8)

Thunderbird Autoconfig: Automatische E-Mail-Konfiguration für den eigenen Mailserver

Thunderbird kann sich selbst konfigurieren. Der Benutzer gibt E-Mail-Adresse und Passwort ein, Thunderbird sucht die Servereinstellungen automatisch — kein Eintippen von Hostnamen, Ports oder Verschlüsselungsoptionen. Das funktioniert nicht nur bei Gmail oder GMX, sondern auch mit dem eigenen Mailserver. Man muss nur eine XML-Datei an der richtigen Stelle bereitstellen.

Wo Thunderbird nach der Konfiguration sucht

Thunderbird arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig:

1. Thunderbird ISPDB — Mozilla pflegt eine zentrale Datenbank mit Konfigurationen für große Provider. Steht die Domain dort, ist sofort alles konfiguriert. Für eigene Mailserver irrelevant.

2. autoconfig.<domain> — Thunderbird fragt https://autoconfig.example.org/mail/config-v1.1.xml. Das ist der Weg, den wir nutzen. Ein CNAME im DNS, ein Webserver mit gültigem TLS-Zertifikat, eine statische XML-Datei — fertig.

3. .well-known auf der Domain — Thunderbird versucht https://example.org/.well-known/autoconfig/mail/config-v1.1.xml. Funktioniert, wenn die Domain selbst einen Webserver hat. Braucht keinen eigenen Hostnamen.

4. MX-Heuristik — Als Fallback versucht Thunderbird gängige Hostnamen wie imap.example.org und smtp.example.org mit üblichen Ports und Verschlüsselung. Klappt oft, ist aber Glückssache.

5. Manuell — Wenn nichts funktioniert, muss der Benutzer alles von Hand eingeben. Genau das wollen wir vermeiden.

Die config-v1.1.xml

Die XML-Datei beschreibt alle Servereinstellungen. Thunderbird liest sie und konfiguriert das Konto automatisch. Hier die Version, die ich für alle meine Maildomains einsetze:

<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
  <emailProvider id="kernel-error.de">
    <domain>kernel-error.de</domain>
    <domain>kernel-error.com</domain>
    <domain>vandemeer.de</domain>
    <domain>fuchs-meckenheim.de</domain>
    <domain>heidbreders.de</domain>
    <domain>linux-rheinbach.de</domain>
    <domain>rfc-ignorant.de</domain>

    <displayName>kernel-error.de Mail</displayName>
    <displayShortName>kernel-error</displayShortName>

    <incomingServer type="imap">
      <hostname>imap.kernel-error.de</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

    <outgoingServer type="smtp">
      <hostname>smtp.kernel-error.de</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

Wichtige Details:

%EMAILADDRESS% — Thunderbird ersetzt das automatisch durch die eingegebene E-Mail-Adresse. Kein PHP nötig, kein dynamisches Script — eine statische Datei reicht. Das ist der große Unterschied zu Outlook Autodiscover, wo ein PHP-Script die E-Mail-Adresse aus dem POST extrahieren muss.

password-cleartext — Klingt gefährlich, ist es nicht. Es bedeutet, dass das Passwort über die TLS-verschlüsselte Verbindung gesendet wird. Der Name ist irreführend — Mozilla meint damit „Klartext innerhalb des verschlüsselten Kanals“ im Gegensatz zu Challenge-Response-Verfahren wie CRAM-MD5.

Port 465 (implizites TLS) — Die Verbindung ist sofort verschlüsselt, kein STARTTLS-Handshake nötig. Ein Eintrag reicht — Thunderbird braucht keinen Fallback.

Mehrere <domain>-Einträge — Eine XML-Datei für alle Maildomains. Thunderbird prüft, ob die Domain der eingegebenen E-Mail-Adresse in der Liste steht.

DNS und Webserver

Für jede Maildomain wird ein DNS-CNAME angelegt:

autoconfig.vandemeer.de.  IN CNAME www.kernel-error.de.

Alle CNAMEs zeigen auf denselben Webserver. Dort braucht jeder Hostname einen eigenen HTTPS-Server-Block mit passendem TLS-Zertifikat — Thunderbird akzeptiert keine Zertifikatsfehler. Die Nginx-Konfiguration ist simpel:

server {
    listen      [::]:443 ssl;
    listen      443 ssl;
    server_name autoconfig.vandemeer.de;

    ssl_certificate     /usr/local/etc/letsencrypt/live/vandemeer.de/fullchain.pem;
    ssl_certificate_key /usr/local/etc/letsencrypt/live/vandemeer.de/privkey.pem;

    location /mail/ {
        alias /usr/local/www/autoconfig-mail/mail/;
    }
}

Das TLS-Zertifikat muss autoconfig.vandemeer.de als SAN enthalten. Bei Let’s Encrypt reicht ein certbot --cert-name vandemeer.de -d vandemeer.de -d www.vandemeer.de -d autoconfig.vandemeer.de beim nächsten Renewal.

Für Domains mit Wildcard-Zertifikat (*.kernel-error.de) entfällt das — der Hostname ist direkt abgedeckt.

Unterschied zu Outlook Autodiscover

Thunderbird und Outlook lösen dasselbe Problem auf unterschiedlichen Wegen:

Thunderbird Autoconfig — Statische XML-Datei, %EMAILADDRESS% als Platzhalter, GET-Request, kein serverseitiges Scripting nötig.

Outlook Autodiscover — POST-Request mit E-Mail-Adresse im Body, PHP-Script extrahiert den Benutzernamen dynamisch, DNS SRV-Records statt CNAME. Details dazu: Outlook Autodiscover für IMAP/SMTP

Beide können auf demselben Webserver laufen. Bei mir bedient autodiscover.kernel-error.de Outlook per POST und liefert gleichzeitig /mail/config-v1.1.xml für Thunderbird aus.

Fragen? Gerne per Kontaktseite.

DKIM Schüssel getauscht

Nachdem nun alle etwas nervös wegen zu kurzer DKIM Keys sind (512Bit), diese lassen sich wohl bei Amazon in knapp 72 Stunden knacken. Habe ich dann meine Schlüssel auch einmal getauscht. Diese hatten bisher eine Länge von 1024 Bit, mit diesen wäre ich also noch locker auf der sicheren Seite denn noch kann es ja nicht schaden sie auf 2048Bit aufzubohren. Fast alle Systeme können mit diesen inzwischen umgehen. Die Leistung aktueller Systeme sollte heute ebenfalls nicht sonderlich unter diesen Schlüssellänge leiden.

Die Schlüssel sind schnell erstellt:

$ dkim-genkey -b 2048 -s kernel-error.de -d kernel-error.de

Wie gewohnt habe ich dann den TXT-RECORD in mein Zonenfile gekippt. Beim signieren der Zone per DNSsec sprang mich aber folgende Fehlermeldung an:

dnssec-signzone: error: dns_rdata_fromtext: kernel-error.de:25: ran out of space

Na nu? Ach so… ja klar! Der TXT-RECORD ist zu lang. Da gibt es ja eine Beschränkung…. Fast vergessen! Mehr als 255 Zeichen sind ja nicht zulässig. Ich musste den DKIM TXT-RECORD also in ein multi-line TXT-RECORD umwandeln. Nicht weiter kompliziert, einfach Klammer auf, Klammer zu und alles brav mit Anführungszeichen trennen. Damit sieht mein Zoneneintrag nun wie folgt aus:

kernel-error.de._domainkey IN TXT ( "v=DKIM1; g=*; k=rsa; "
                    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1V7WG+ZchvAxfJ2wi9jn7vWVs2mDkk66cqrKjTETdbuPwL"
                    "CX4N4IXTemT7SMS2Z+gTxcPNnUCorcMsXigNlGJK4Oq8GNx0fcxbXB+vq522FpM6FY8FVTfhL7bqLg5ajp9k0boJnSRv"
                    "F4wY3nci6E7CYCdP9XjHVoOciJdlrGFMo8rYGGiI9Ubgvue8etqgPCV2T8BKEZgys7kabPyaujSHmqrPbBkjb/F+QPJH"
                    "WqcyD7ywfT5vUkrj40Qiwsr7HxGk9aYCAHwyvdP4dvXd5xfMH2QlRKbrMjIQfKJfD5cfTiAl7YgFBFO1n7Wfj5syB6FE"
                    "bRZR9HO+rusv0hojiViQIDAQAB" )

Schnell noch mit einer Testmail an: check-auth@verifier.port25.com prüfen ob alles korrekt ist.

Fertig….

----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: kernel-error@kernel-error.com)
ID(s) verified: header.d=kernel-error.com
Canonicalized Headers:
    To:'20'<check-auth@verifier.port25.com>;'0D''0A'
    Subject:'20'check-auth@verifier.port25.com'0D''0A'
    MIME-Version:'20'1.0'0D''0A'
    Content-Type:'20'text/plain;'20'charset=UTF-8;'0D''0A'
    '20'format=flowed'0D''0A'
    Content-Transfer-Encoding:'20'7bit'0D''0A'
    Date:'20'Fri,'20'09'20'Nov'20'2012'20'11:33:48'20'+0100'0D''0A'
    From:'20'Sebastian'20'van'20'de'20'Meer'20'<kernel-error@kernel-error.com>;'0D''0A'
    Message-ID:'20'<c580aed4c89d48c1a93fea35ee80fe30@vandemeer.de>;'0D''0A'
    DKIM-Signature:'20'v=1;'20'a=rsa-sha256;'20'c=simple/simple;'20'd=kernel-error.com;'0D''0A'
    '09's=kernel-error.com;'20't=1352457228;'0D''0A'
    '09'bh=v55t4Oe0VsnE3Xa3exogjgnS10dkjG1rhPQxGz4STJo=;'0D''0A'
    '09'h=To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:'0D''0A'
    '09''20'Date:From:Message-ID;'0D''0A'
    '09'b=

Canonicalized Body:
    check-auth@verifier.port25.com'0D''0A'
    

DNS record(s):
    kernel-error.com._domainkey.kernel-error.com. 300 IN TXT "v=DKIM1; g=*; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlhidIl+KZgelAOOVYiGHi+uGxEnpjmhXH2IVZNpH69ZsWYTYd1OgXIvWQnAiQ4rRCyvbjcrKaFnXJUpda9eGJeqlr3hE4YhOPLS34K86+8Gr17+WOofkdc3STmlqAI60r1+bQQh8rCWb1YPXIssinq3ll8GVDwAEmh3Bm8zSWz2Ntc+W/maURTlZbMGaRoi+lwhBzr+DnNYL+mPs3UVQoE9ei2Z/bjNQzdpzWeriFgfk56muVZNTvmn8LxkugMhoHMohCr/vkr99xTVmIeMFwMerB2B/JOpeADIf4Wsz6OJQR3GaBA91MX9T2nFncvW3pL03O4wYYVCGnFqz8gbcQIDAQAB"

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

 

Siehe auch: DKIM einrichten

Fragen? Einfach melden.

Postfix für sichere E-Mail-Auslieferung: Nur noch per TLS konfigurieren

Verschlüsselte E-Mail-Übertragungen sind meist ganz gut. Zumindest hält sie einem lästige Lauscher vom Hals. Besonders wichtig ist dabei der verschlüsselte Austausch zwischen Mail-Server und Mail-Client. Denn die User sitzen mit ihren Mail-Clients sehr schnell in einem „unsicheren“ Netzwerk. Daher wird inzwischen sehr oft und gut darauf geachtet diese Verbindungen zu sichern.

Die Verbindungen zwischen den Servern werden oft als nicht SO wichtig empfunden. Denn die Kisten stehen ja meist in gesicherten Bereichen (Serverraum, DMZ, Rechenzentrum) und dort zu lauschen ist schon aufwendiger – nicht unmöglich.
Es macht also Sinn seinem Postfix zu ermöglichen seine Server zu Server Verbindungen kryptisch zu gestalten.

Mit folgender Änderung sagt man seinem Postfix dass bei ausgehenden Verbindungen TLS benutzt werden kann, wenn möglich.

$ postconf -e smtp_tls_security_level=may

Wird Postfix nun ein Zertifikat gereicht, welches von Postfix mangels der Root-Zertifikate nicht geprüft werden kann… Ja, dann ist hier schon wieder Ende.

Sep 25 10:38:07 rootserver postfix/qmgr[2069]: D69471A2026: from=<kernel-error@kernel-error.com>;, size=38273, nrcpt=1 (queue active)
Sep 25 10:38:07 rootserver postfix/smtp[9454]: certificate verification failed for gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

Auf Debian Systemen finden sich eine recht gepflegte Ansammlung im Paket: ca-certificates. Nachdem dieses installiert ist:

$ apt-get install ca-certificates

Sagt man Postfix noch wie er es findet:

$ postconf -e smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Schon sollte Postfix in der Lage sein, ausgehende Serververbindungen zu prüfen und zu verschlüsseln.

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Mehr als nur A-Records

Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:

GPG im DNS: http://www.kernel-error.de/dnssec/gpg-im-dns

SSH-Key im DNS: http://www.kernel-error.de/dnssec/ssh-key-im-dns

Fragen? Einfach melden.

OpenSSL ich kann es mir nicht merken

Jetzt mal unter Freunden, was ist bloß los mit meinem Kopf? Da aktiviere ich gerade für einen Kunden am Microsoft Exchangeserver Outlook Anywhere. Der Kunde hat ein selbstsigniertes Zertifikat auf seinem Server. Also quängelt Outlook natürlich bei der Verbindung über https „Das böse Zertifikat vom bösen Proxyserver… bla bla“. Nun will ich einfach mal schnell das Zertifikat haben um es auf der Windose importieren zu können und reiße schnell auf meiner Solariskiste ein Terminalfenster auf und tippe:

# openssl öhm ähhh öhm… *MIST*

Warum kann ich mir das nicht merken? Irgendwas mit sclient slclient?!?! Dann aber sicher -connect und host:port. Es kann doch nicht sein dass ich jedes mal in die Manpage schauen muss oder?

Folgendes ist natürlich der richtige Aufruf:

$ openssl s_client -connect www.kernel-error.de:443

Vielleicht schaffe ich es ja jetzt mir mal zu merken das es s_client heißt, nachdem ich es hier aufgeschrieben habe. Warum zum Teufel kann ich mir s_client einach nicht merken? Das regt mich auf!

 

 

 

 

Siehe auch: PEM zu PFX konvertieren

Fragen? Einfach melden.

Evolution merkt sich die Einstellungen der Zertifizierungsstellen nicht

Ich nutze Evolution als E-Mail Client. In den Zertifikatseinstellungen habe ich unter Zertifizierungsstellen auch eine ganze Latte von CAs. Ich kann auch welche hinzufügen und entfernen alles kein Problem.

Will ich aber deren Einstellung bearbeiten, sprich für welche Dinge ich dieser CA vertrauen möchte bleiben diese Einstellungen nur immer für die aktuelle Sitzung gespeichert. Schließe und Starte ich Evolution wieder sind die Einstellungen alles wieder weg 🙁 Das ist doof!

Wer sucht, der findet einen Workaround……..

Das Problem ist wohl dass Evolution aus irgendwelchen Gründen die cert9.db / key4.db unter ~/.pki/nssdb nicht updatet.

So kann ich mir anschauen was bei mir eingetragen ist:

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. ,,   
CA Cert Signing Authority - Root CA                          ,,   
CAcert Class 3 Root - Root CA                                ,,   
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. ,,   
StartCom Certification Authority - StartCom Ltd.             ,,   
StartCom Ltd.                                                ,,   
StartCom Certification Authority                             ,,   
......

Und so verpasse ich den einzelnen Zertifikaten die passenden „Verwendungsmöglichkeiten“:

$ certutil -M  -n "CA Cert Signing Authority - Root CA"  -t "TCu,Cu,TCuw" -d sql:/home/kernel/.pki/nssdb/

Am Ende schaut es nun so aus (ich mache mir dann noch mal nen Kopf ob es so auch sinnig ist):

$ certutil -L -d sql:/home/kernel/.pki/nssdb/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

StartCom Ltd. ID von Sebastian Van De Meer                   u,u,u
StartCom Class 2 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
CA Cert Signing Authority - Root CA                          CT,C,C
CAcert Class 3 Root - Root CA                                CT,C,C
StartCom Class 1 Primary Intermediate Client CA - StartCom Ltd. CT,C,C
StartCom Certification Authority - StartCom Ltd.             C,C,C
StartCom Ltd.                                                C,C, 
StartCom Certification Authority                             C,C,C
......

Auf meine Openindiana Kiste musste ich dafür noch folgendes Paket installieren:

system/mozilla-nss

Und wegen des Bugs #1739 certutil with incomplete runpath musste ich noch folgenden Workaround dafür einwerfen:

$ elfedit -e 'dyn:runpath $ORIGIN/../lib:/usr/lib/mps' /usr/sfw/bin/certutil

Jetzt macht zwar Evolution nicht die Arbeit aber mein Wunsch ist erfüllt. Ob ich da mal nen Bug bei den Jungs aufmache?

So long…

Siehe auch: S/MIME per DNS mit SMIMEA

Fragen? Einfach melden.

ZFS-Verschlüsselung: Datasets und Homedirectories unter Solaris verschlüsseln

Hinweis: Dieser Artikel beschreibt die ZFS-Verschlüsselung unter Solaris 11 und OpenIndiana. Unter OpenZFS (FreeBSD 13+, Linux) gibt es seit 2019 native Verschlüsselung mit zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset — das funktioniert ohne die Solaris-spezifischen PAM-Module. Für verschlüsselte Backups auf FreeBSD mit geli siehe ZFS-Backup auf USB-Platte mit geli.

Verschlüsseltes Dataset anlegen

Ab ZFS Version 30 lässt sich ein Dataset beim Erstellen verschlüsseln — mit AES-128, AES-192 oder AES-256. Bei Schlüsseln größer 128 Bit macht eine Hardwarebeschleunigung Sinn (SPARC T2/T3, Intel AES-NI). Für die meisten Szenarien reicht AES-128 völlig aus.

zfs create -o encryption=on rpool/export/home/kernel/DatenSafe
Enter passphrase for 'rpool/export/home/kernel/DatenSafe':
Enter again:

Nach einem Reboot wird das verschlüsselte Dataset nicht automatisch eingehängt — man muss es manuell mounten:

zfs mount rpool/export/home/kernel/DatenSafe
Enter passphrase for 'rpool/export/home/kernel/DatenSafe':

Schlüssel als Datei

Statt einer Passphrase kann der Schlüssel auch als Datei auf einem USB-Stick liegen:

zfs create -o encryption=on -o keysource=raw,file:///media/usb-stick/schluessel \
  rpool/export/home/kernel/DatenSafe

Dann den USB-Stick getrennt vom System aufbewahren — und eine Kopie des Schlüssels an einem sicheren dritten Ort. Ohne Schlüssel oder Passphrase sind die Daten nicht wiederherstellbar.

PAM-Integration: Verschlüsselte Homedirectories (Solaris 11)

Unter Solaris 11 gibt es ein PAM-Modul (pam_zfs_key.so.1), das den Encryption Key des ZFS-Homedirectories an das Unix-Passwort des Benutzers koppelt. Beim Login wird das Homedirectory automatisch entschlüsselt und eingehängt — transparent für den Benutzer, funktioniert mit Konsole, SSH und GDM.

Konfiguration in /etc/pam.conf:

login auth     required pam_zfs_key.so.1 create
other password required pam_zfs_key.so.1

sshd-kbdint     auth requisite          pam_authtok_get.so.1
sshd-kbdint     auth required           pam_unix_cred.so.1
sshd-kbdint     auth required           pam_unix_auth.so.1
sshd-kbdint     auth required           pam_zfs_key.so.1 create

gdm     auth requisite          pam_authtok_get.so.1
gdm     auth required           pam_unix_cred.so.1
gdm     auth required           pam_unix_auth.so.1
gdm     auth required           pam_zfs_key.so.1 create

Neuen Benutzer anlegen und beim ersten Login zur Passwortänderung zwingen — dabei wird das verschlüsselte Homedirectory automatisch erstellt:

useradd sebastian
passwd sebastian
passwd -f sebastian

Beim ersten Login passiert alles automatisch:

login: sebastian
Password:
Choose a new password.
New Password:
Re-enter new Password:
login: password successfully changed for sebastian
Creating home directory with encryption=on.
Your login password will be used as the wrapping key.

Prüfen:

zfs get encryption,keysource rpool/export/home/sebastian
NAME                             PROPERTY    VALUE              SOURCE
rpool/export/home/sebastian      encryption  on                 local
rpool/export/home/sebastian      keysource   passphrase,prompt  local

So sieht der Vorgang im GDM (Gnome Display Manager) aus:

GDM-Benutzeranmeldung unter Solaris 11 mit ZFS-Homedirectory-Encryption.
Eingabe des initialen Passworts im GDM.
GDM fordert zur Passwortänderung auf.
Eingabe des neuen Passworts im GDM.
Wiederholte Eingabe des neuen Passworts im GDM.
GDM bestätigt die Passwortänderung.
GDM bestätigt das Anlegen des verschlüsselten Homedirectories.

Bestehendes Homedirectory nachträglich verschlüsseln

Ein bestehendes ZFS-Dataset lässt sich nicht nachträglich verschlüsseln. Der Weg: Dataset umbenennen, Benutzer zur Passwortänderung zwingen (erstellt neues verschlüsseltes Home), Daten zurückkopieren:

# Als anderer Admin mit root-Rechten:
zfs rename -f rpool/export/home/kernel rpool/export/home/kernel-alt
passwd -f kernel

# Nach dem Login (neues verschlüsseltes Home wurde angelegt):
cp -rp /export/home/kernel-alt/* /export/home/kernel/
zfs destroy rpool/export/home/kernel-alt

Wichtig: Die alten unverschlüsselten Daten liegen nach dem Destroy noch physisch auf der Platte und werden erst nach und nach überschrieben. Für echte Sicherheit müsste man die gesamte Platte überschreiben — oder besser: gleich bei der Installation verschlüsseln.

Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

StartSSL

Veraltet: StartSSL/StartCom wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. Für kostenlose Zertifikate nimmt man heute Let’s Encrypt.

StartCom ist ein Unternehmen, das Software herstellt und als Zertifizierungsstelle digitale Zertifikate ausstellt. Seit Februar 2005 ist das Unternehmen als Zertifizierungsstelle tätig. Das bekannteste Produkt ist das kostenlose Class 1 X.509 SSL-Zertifikat „StartSSL Free“, das sowohl für Webserver (SSL/TLS) als auch für die E-Mail-Verschlüsselung (S/MIME) eingesetzt werden kann. Außerdem werden Class 2 Zertifikate und Extended-Validation-SSL-Zertifikate ausgestellt, für die eine kostenpflichtige Validierung Voraussetzung ist. StartCom-Zertifikate werden von allen modernen Browsern akzeptiert: Mozilla Firefox unterstützt sie schon ab Version 2.0, Opera seit Juli 2010, Apple Mac OS X ab Version 10.5 (Leopard) und Microsoft Windows seit September 2009; Apple Safari, Internet Explorer und Google Chrome greifen auf den Zertifikatspeicher des Betriebssystems zurück.

Das kostenlose Class1 Zertifikat stellt nur sicher das der angegebene Domainname existiert und anscheinend dem Halter des StartCom Accounts gehört. Aus diesem Grund findet sich natürlich auch nur der Domainname im Zertifikat. Wer seinen Namen auch noch im Zertifikat hinterlegen möchte kann dieses denn noch auf einem kostenlosen Weg schaffen. Ähnlich CAcert setzt StartCom auf das Prinzip des Web of Trust (wot). Es gibt bei StartCom ehrenamtliche Notare. Jeder Inhaber eines StartCom Accounts kann sich von diesen verifizieren lassen. Dazu findet sich im Webinterface des eigenen Accounts auf der Seite unter StartSSL WoT ==> WoT Netzwerk der Punkt Notarsucher. Hier findet sich über die Eingabe des eigenen Wohnortes oder halt der nächsten größeren Stadt schnell ein solcher Notar.

Wurde man von mindestens zwei dieser Notare bestätigt, kann man seinen Namen mit ins Zertifikat aufnehmen.

Eine solche Bestätigung findet immer über ein persönliches Treffen mit dem Notar statt. Bei diesem Treffen prüft der Notar anhand von zwei amtlichen Lichtbildausweisen ob der Name im Account mit dem auf den Ausweisen identisch ist.

Da die Root-Zertifikate dieser Zertifizierungsstelle bereits in den meisten großen Browsern und Betriebssystemen enthalten sind, kommt es bei diesen Zertifikaten (anders als bei z.B. CAcert.org) nicht zu „Fehlermeldunge“ bzw. Warnmeldungen im Zusammenhang mit den Zertifikaten. Vor allem dieser Umstand und natürlich da es kostenneutral ist, würde ich StartCom x.509 Zertifikate als einen optimalen Einstieg in diesen Themenbereich nennen können. Wer am Ende mehr will, wie eine Class 2 Zertifizierung oder bis hin zum Class 3 Zertifikat für Unternehmen, kann dieses schnell und günstig weiterführen. Wem das Class 1 Zertifikat ausreicht, dem stehen direkt nach der erfolgreichen Anmeldung schon fast alle Möglichkeiten der E-Mail Signatur / Verschlüsselung sowie SSL/TLS Verschlüsselte Serververbindungen offen.

Ich selbst bin bei StartSSL Notar und wie bei GPG / PGP oder CAcert.org bestätige ich auch hier gerne Identitäten auf Anfrage.

Eigenen Jabber-Server betreiben: Warum und wie mit Openfire

Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.

Warum ein eigener Server

Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.

Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.

Openfire

Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.

Die Installation unter Debian ist schnell erledigt. Die TLS-Konfiguration braucht etwas Handarbeit, dazu gibt es eigene Beiträge: Unsichere Cipher deaktivieren und S2S-Verbindungen mit fehlenden Intermediate-Zertifikaten.

Jabber auf dem DECT-Telefon

Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.

Gigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem MessangerGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue NachrichtGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue Nachricht
Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden.Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen.Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso.

Fragen? Einfach melden.

CAcert in Firefox

Veraltet: CAcert-Zertifikate wurden nie in die Standard-Truststores der Browser aufgenommen. Kostenlose TLS-Zertifikate gibt es bei Let’s Encrypt.

CAcert ist eine feine Sache. Leider sind deren Root-Zertifikate noch nicht in allen Browsern und Programmen integrieret.

Ich habe mir nun Gedanken dazu gemacht:

Wie schaffe ich es die CAcert-Root-Zertifikate in Anwendungen von Microsoft (Word, Outlook, Internetexplorer..) und Mozilla (Thunderbird, Firefox…) so zu integrieren das sie immer als vertrauenswürdig erkannt werden? Auch bei allen anderen Usern auf dem System und denen die später noch ein neues Konto bekommen…

Natürlich könnte ich bei jedem User die Zertifikate einzeln mit der Hand importieren und als vertrauenswürdig einstufen.  Es ist aber sehr aufwändig und bestimmte User haben damit ein, nennen wir es Problem! Es muss also automatisch gehen.

Für die Microsoftprodukte habe ich eine einfache Lösung gefunden. Mit >>dieser<< Regestrierungsdatei werden die CAcert-Root-Zertifikate automatisch ins System übernommen. Ab diesem Moment sind in allen Microsoftanwendungen, bei allen Usern (vorhandenen und neuen) eines Systems die Zertifikate gültig.

Bei Mozilla ist es nicht ganz so einfach. Hier geht es am einfachsten so:

!!Firefox sollte noch nicht auf dem System installiert sein!!

Zuerst besorgt man sich die Installationsdatei für den Firefox. Am einfachsten wohl hier:  http://www.mozilla-europe.org/de/firefox/

CAcert certificate import in Firefox, step 1

Dann installiert man den Firefox wie gewohnt, startet ihn und importiert die CAcert-Root-Zertifikate als vertrauenswürdig. Jetzt Firefox zu machen und lassen! Bisher alles klar und einfach. Aber nun…

CAcert certificate import in Firefox, step 2

Jetzt sucht man unter: Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\ die Datei cert8.db. Gefunden? Gut… Merken wo!

CAcert certificate import in Firefox, step 3

Jetzt das Firefoxinstallerpacket entpacken. Am einfachsten vielleicht mit WinRAR.

CAcert certificate import in Firefox, step 4

Nun kopiert man die cert8.db in den, gerade entpackten Ordner, Firefox Setup 3.0.1\localized\defaults\profile\

CAcert certificate import in Firefox, step 5

Startet man nun die Firefoxinstallation über die setup.exe sind die CAcert-Root-Zertifikate immer automatisch im Firefox integriert. Da immer wenn ein User das erste mal den Firefox startet, sein default Profile zusammengestellt wird. Es wird also immer die cert8.db mit in sein Profil kopiert. In dieser liegen die Zertifikate. Also auch unserer importierten CAcert-Root-Zertifikate. Dieses Packet könnte man nun immer für seine Installationen nutzen und vielleicht auch weitergeben. Will man allen existierenden Usern die Zertifikate unterschieben, muss man einfach nur die cert8.db in dessen Ordner packen (Dokumente und Einstellungen\seinUsername\Anwendungsdaten\Mozilla\Firefox\Profiles\irgendwas.default\).

So funktioniert es auch unter Thunderbird. Bei Linux funktioniert es auch über diese Datei.

Ich diese Infos helfen dem Einen oder Anderen. Wenn noch jemand Infos dazu hat, freue ich mich natürlich über zuschriften!

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑