IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 34 von 45)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

StartSSL Identiy Validation Class 2

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose Zertifikate gibt es bei Let’s Encrypt.

Na wunderbar, mein Class 2 x.509 S/MIME Zertifikat läuft in kürze aus. Die Class 2 Validation ist auch ausgelaufen, also muss ich wohl was tun, hm?


Schnell alles bei StartSSL angeschoben und auf den bekannten Anruf irgendwo aus Israel warten… Es klingelte auch aber aus 001 213-341. Die Landesvorwahl ist USA und mein Android meint der Rest wäre etwas aus Los Angeles, CA! Das hat mich etwas überrascht; whatever. Wie gewohnt war das Gespräch schnell erledigt. Wobei die Dame am anderen Ende der Leitung extrem schlecht zu verstehen war. Nun warte ich also auf die Bestätigung meiner Class 2 Zertifizierung.

 


 

*UPDATE*

Na wunderbar:

### Schnipp ###
To Sebastian Van De Meer,

This electronic mail message was created by StartCom’s Administration Personnel:

Congratulations! Your Class 2 Identity Validation has been confirmed and approved. You are eligible for certificates at Class 2 level until 2014-05-01.
Additionally you have been awarded with StartSSL™ Web-of-Trust Notary status due to your fulfilling of all requirements. Well done!

Best Regards
### Schnapp ###

Dann kann ich ja gleich mal von diesem Zertifikat:

Seriennummer: 13:27
SHA1-Fingerprint: 28:AE:4C:96:51:75:EB:18:03:F9:9E:E3:7A:ED:C7:EA:13:8B:44:99

Zu diesem Zertifikat wechseln:

Seriennummer: 33:97
SHA1-Fingerprint: 7F:8B:92:19:FF:07:BF:EB:8E:E0:18:D4:98:B8:48:DF:E3:0E:4A:85

 

 

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.

Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!

Wie also nun aus PEM ein PFX machen? Openssl hilft:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

Buchtipp Kabelsalat

Vor einiger Zeit ist mir ein Buch mit dem Titel: „Kabelsalat: Wie ich einem kaputten Kabel folgte und das Innere des Internets entdeckte“ empfohlen worden. Die Zeit ein Buch zu lesen habe ich leider im Moment weniger. Die Beschreibung klang aber so spannend, dass ich mir das Buch besorgte. Bestellt und geliefert ist so ein Buch ja schnell.

Inzwischen habe ich es auch gelesen. Das Buch ist –nicht schlecht-. Das Thema des Buches, die Beschreibung der Reise und vor allem die besuchten Orte sind sehr einmalig und nett beschrieben. Alles ist dabei nicht so technisch, dass man es nicht verstehen würde. Ich glaube selbst meine Mutter könnte es ohne Probleme lesen und verstehen. Nur ist es eines dieser Bücher das man nur lesen kann, wenn man sich dafür interessiert. Das Buch ist also nicht schlecht, für jemanden der sich aber für das Thema und die groben Zusammenhänge des Internets interessiert, der sollte dieses Buch unbedingt lesen!
Ach ja, ISBN: 3813503887

Bild des Buches Kabel Salat von Andrew Blum für eine Buchempfehlung.

Fragen? Einfach melden.

Citrix XenServer Kernel Module automatisch beim Booten starten

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.

Möchte man bei seinem Citrix Xen Server bestimmte Kernelmodule automatisch beim Booten laden, hilft folgendes.

Einfach unter /etc/sysconfig/modules/ ein passendes Konfigurationsfile für das Module anlegen und es ausführbar machen. Ich habe hier ein Beispiel für die IPMI Module:

$ echo "modprobe ipmi_si" > /etc/sysconfig/modules/ipmi_si.modules
$ echo "modprobe ipmi_devintf" > /etc/sysconfig/modules/ipmi_devintf.modules
$ chmod +x /etc/sysconfig/modules/ipmi_si.modules
$ chmod +x /etc/sysconfig/modules/ipmi_devintf.modules

 Schon werden die beiden Module ipmi_si und ipmi_devintf beim Boot des Servers geladen!

IPv6 – Neighbor Discovery – Openindiana – Solaris 11 – Opensolaris

Veraltet: Dieser Beitrag bezieht sich auf IPv6 Neighbor Discovery unter Solaris/OpenIndiana. Das Konzept (NDP statt ARP) gilt weiterhin, die gezeigten Befehle sind aber Solaris-spezifisch. Unter Linux: ip -6 neigh show.

Damit IPv4 im Ethernet funktioniert braucht man das ARP (Address Resolution Protocol) als Unterbau. Denn sonst würden die IPv4 Pakete ja ihren Weg nicht zur richtigen Netzwerkkarte finden. ARP und IPv4 sind dabei völlig unabhängige Protokolle, sie arbeiten nur seit Jahrzenhten Hand in Hand. Das vergessen viele schnell.

Möchte man also nun herausfinden welche MAC Adresse das System (im gleichen Ethernet-Netzwerk) hat, mit welchem man sich gerade unterhält… Ja, dann bemüht man das ARP.

Unter Linux:

$ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
errorgrab.kernel-error.  ether   00:ff:c9:05:01:c7   C                     enp2s0
wurstsuppe.kernel-error. ether   50:ff:5d:85:73:48   C                     enp2s0

Unter Openindiana/Solaris 11:

$ arp -a
Net to Media Table: IPv4
Device   IP Address               Mask      Flags      Phys Addr
------ -------------------- --------------- -------- ---------------
rge0   router.kernel-error      255.255.255.255          00:ff:42:72:2b:a6
rge0   192.168.1.31         255.255.255.255          00:ff:b0:ae:0b:eb
rge0   sebastian-solaris.kernel-error 255.255.255.255 SPLA     80:ff:73:4a:38:c7
rge0   all-routers.mcast.net 255.255.255.255 S        01:ff:5e:00:00:02

Bei IPv6 schaut es nun etwas anders aus. Man könnte sagen, hier wurde ARP direkt mit in IPv6 integriert. Es findet sich im Neighbor Discovery wieder. Möchte man hier seine „Nachbarn“ sehen klappt es so:

Unter Linux:

$ ip -6 neigh show
fe80::1 dev enp2s0 lladdr 50:ff:5d:85:73:48 router STALE
fe80::2ff:c9ff:fe05:1c7 dev enp2s0 lladdr 00:ff:c9:05:01:c7 router REACHABLE

Unter Openindiana/Solaris 11:

$ netstat -pf inet6

Net to Media Table: IPv6
 If   Physical Address    Type      State      Destination/Mask
----- -----------------  ------- ------------ ---------------------------
rge0  33:33:ff:00:00:01  other   REACHABLE    ff02::1:ff00:1             
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    router.kernel-error
rge0  33:33:00:00:00:01  other   REACHABLE    ff02::1                    
rge0  33:33:00:01:00:02  other   REACHABLE    ff02::1:2                  
rge0  33:33:ff:00:00:06  other   REACHABLE    ff02::1:ff00:6             
rge0  33:33:ff:10:98:82  other   REACHABLE    ff02::1:ff10:9882          
rge0  33:33:ff:ad:7a:dd  other   REACHABLE    ff02::1:ffad:7add          
rge0  33:33:ff:00:00:11  other   REACHABLE    ff02::1:ff00:11            
rge0  33:33:00:00:00:16  other   REACHABLE    ff02::16                   
rge0  46:ff:91:30:98:3d  dynamic REACHABLE    2001:7d8:8001:0:ffff:bdb9:6810:9882
rge0  80:ff:73:4a:38:c7  local   REACHABLE    sebastian-solaris.kernel-error
rge0  80:ff:73:4a:38:c7  local   REACHABLE    fe80::ffff:73ff:fe4a:38c7  
rge0  00:ff:42:72:2b:a6  dynamic REACHABLE    fe80::fff:42ff:fe72:2ba6   
rge0  33:33:ff:4a:38:c7  other   REACHABLE    ff02::1:ff4a:38c7

Früher war es mit dem ARP „einfacher“. Zumindest musste man sich nur einen Befehl merken und dann halt die für das jeweilige Betriebsystem nötigen Schalter herausfinden. Mit IPv6 ist es nun mit in die jeweiligen IP-Tools gewandert. Ich halte es für sauberer auch wenn man sich nun nicht mehr mit den Befehlt „arp“ behelfen kann.

BSD und ihre Ableger nutzen „ndp„.
Bei Linux verschwindet alles in den iproute2-Tools mit dem Befehl: „ip“ (ifconfig, route, usw. usw…. alles im Tool ip)
Microsoft wirft alles in „netsh„.
Unixbasierendes hält sich ans gute alte „netstat„.

Also bis dahin…

Openindiana / Solaris 11 MAC Adresse der Netzwerkkarte anzeigen

Veraltet: Solaris und OpenIndiana werden kaum noch eingesetzt. Unter Linux: ip link show, unter FreeBSD: ifconfig.

Es ändert sich im Laufe der Zeit ja mal immer wieder etwas. So auch der Weg mit Netzwerkkarten umzugehen unter Solaris.
Wer also gerade versucht die MAC Adresse seiner lokalen Netzwerkkarte / NIC herauszufinden, dem wird folgender Command helfen:

$ pfexec dladm show-phys -m
LINK         SLOT     ADDRESS            INUSE CLIENT
rge0         primary  80:ee:73:4a:38:c7  yes  rge0

Citrix XenServer: VM fährt nicht herunter – Force Shutdown erzwingen

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Alternativen: Proxmox VE oder XCP-ng.

Hin und wieder bleibt beim Herunterfahren eine VM irgendwie hängen. Dann hat man über das XenCenter keine Möglichkeit mehr diese VM zum Leben zu erwecken. Damit man nun nicht den kompletten VM-Host dom0 neustarten muss, kann man erst folgenden Weg probieren.

Als erstes kann man einen force shutdown der vm probieren:

$ xe vm-shutdown –force vm=“VM-NAME“

Wenn es nicht hilft, kann man versuchen die “wartenden” pending Prozesse am XenServer zu killen:

$ xe task-list

 Dann die Prozesse abbrechen welche den Shutdown zu verhindern scheinen:

$ xe task-cancel uuid=“TASK-UUID“

 Bringt das alles nichts kann man als letztes noch folgendes probieren:

$ xe-toolstack-restart

 Nun kann man noch einmal einen force shutdown probieren. Klappt es auch nicht, muss man wohl doch den VM-Host durchstarten!

Outlook Autodiscover für IMAP/SMTP: Wie die automatische Kontoeinrichtung funktioniert

Benutzer wollen ihr E-Mail-Postfach einrichten. Sie geben E-Mail-Adresse und Passwort ein — den Rest soll der Client erledigen. Bei Exchange mit Active Directory funktioniert das seit Jahren automatisch. Aber was, wenn der Mailserver Postfix und Dovecot heißt und kein Exchange in Sicht ist?

Microsoft Outlook unterstützt auch für IMAP und SMTP die automatische Konfiguration per Autodiscover. Man muss nur wissen, wo Outlook nachschaut — und dort die richtigen Antworten bereithalten.

Outlook Autodiscover für IMAP und SMTP – automatische Mailkonto-Konfiguration über DNS, HTTPS und XML

Wo Outlook nach der Konfiguration sucht

Outlook arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig. Schlägt ein Schritt fehl, geht es zum nächsten:

1. Active Directory (SCP) — Ist der Rechner Domänenmitglied, fragt Outlook per LDAP nach einem Service Connection Point. Dort steht normalerweise die URL des Exchange-Servers. Für reine IMAP-Setups irrelevant.

2. HTTPS auf der E-Mail-Domain — Outlook versucht https://example.org/autodiscover/autodiscover.xml. Funktioniert nur, wenn der Webserver der Domain den Pfad bedient.

3. HTTPS auf autodiscover.<domain> — Outlook versucht https://autodiscover.example.org/autodiscover/autodiscover.xml. Das ist der Weg, den wir nutzen. Ein Webserver unter diesem Hostnamen mit gültigem TLS-Zertifikat — mehr braucht es nicht.

4. HTTP-Redirect — Outlook versucht http://autodiscover.example.org/autodiscover/autodiscover.xml und folgt einem 301/302-Redirect. Weniger sicher, aber ein Fallback.

5. DNS SRV-Record — Outlook fragt _autodiscover._tcp.example.org und folgt dem SRV-Eintrag. Bei einem SRV-Verweis auf eine andere Domain zeigt Outlook eine Sicherheitsabfrage: „Konfiguration von dieser Webseite zulassen?“ Einmalig bestätigen, danach läuft es.

6. Lokale XML-Datei — Outlook sucht auf dem Rechner nach einer vorinstallierten Konfigurationsdatei. Für Firmenumgebungen mit Software-Verteilung relevant.

7. Manueller Assistent — Wenn nichts funktioniert hat, öffnet Outlook den Konfigurationsassistenten. Genau das wollen wir vermeiden.

Was Outlook per POST schickt und erwartet

Outlook macht einen HTTP-POST auf /autodiscover/autodiscover.xml und schickt im Body ein XML mit der E-Mail-Adresse des Benutzers:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>benutzer@example.org</EMailAddress>
    <AcceptableResponseSchema>
      http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
    </AcceptableResponseSchema>
  </Request>
</Autodiscover>

Die Antwort enthält IMAP- und SMTP-Einstellungen. Der Clou: Weil Outlook die E-Mail-Adresse im POST mitschickt, kann ein PHP-Script sie auslesen und als <LoginName> in die Antwort einsetzen. Ohne diesen Trick würde Outlook nur den Teil vor dem @ als Benutzernamen verwenden — bei Mailservern, die die volle E-Mail-Adresse als Login erwarten, ein Problem.

Multi-Domain per DNS SRV-Record

Ein Autodiscover-Webserver reicht für beliebig viele Maildomains. Jede zusätzliche Domain braucht nur einen SRV-Record im DNS:

_autodiscover._tcp.example.org.  IN SRV 0 0 443 autodiscover.kernel-error.de.

Outlook folgt dem SRV-Record, zeigt einmalig die Sicherheitsabfrage, und hat danach die komplette Konfiguration. Das PHP-Script auf dem Zielserver beantwortet Anfragen für alle Domains — die E-Mail-Adresse kommt ja im POST mit.

Umsetzung und aktuelle Konfiguration

Die konkrete Einrichtung — nginx-Konfiguration, PHP-Script und DNS — beschreibe ich im Nachfolgebeitrag: Outlook Autodiscover für IMAP und SMTP konfigurieren. Dort steht auch das Update von 2026 mit den Korrekturen am PHP-Script (GET-Absicherung, XSS-Schutz) und der Zusammenlegung mit Thunderbird Autoconfig.

Wer seine Konfiguration testen will: Microsoft bietet unter testconnectivity.microsoft.com den „Microsoft Remote Connectivity Analyzer“ an. Dort den Autodiscover-Test auswählen und die eigene E-Mail-Adresse eingeben.

Fragen? Gerne per Kontaktformular.

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑