Mailserver 7 von 10: Mailboxen konfigurieren mit mailconf.phs

Jahrelang habe ich mich davor gedrückt, doch endlich ist es geschafft - die Einrichtung eines eigenen Mailservers. In einer kleinen Artikelserie möchte ich einmal meine Erfahrungen und Konfigurationsschritte festhalten. Diese Serie basiert auf zahllosen Tutorials, Best Practices, Gesprächen mit Mailserver-Betreibern, aus endlosem Dokumentationen lesen und dem Wissen der Bücher "Postfix" von Kyle D. Dent und "Postfix - Einrichtung, Betrieb und Wartung" von Ralf Hildebrandt und Patrick Ben Koetter. Vielleicht werden sie ja nützlich für andere Leute sein, die das gleiche erreichen wollen.

Doch eines vorab: Die Einrichtung und der Betrieb eines Mailservers ist eine komplexe Sache. Klar, die Software lässt sich schnell installieren, doch fertig ist man danach noch lange nicht, wenn man ernsthaft damit arbeiten möchte.

Der Fahrplan der Artikelserie:

  1. Einleitung
  2. Mailempfang und Mailversand mit Dovecot und Postfix
  3. Virenprüfung mit ClamAV
  4. Mailsignatur mit OpenDKIM
  5. Spamprüfung mit SpamAssassin
  6. Mailabruf mit Dovecot
  7. Mailboxen konfigurieren mit mailconf.phs
  8. Mails synchronisieren mit mailsync.phs
  9. Mailqueue überwachen mit mailqueue.phs
  10. SpamAssassin anlernen mit maillearn.phs

Langsam aber sicher befinden wir uns auf der Zielgeraden unserer Mailservereinrichtung. Wir können inzwischen Mails empfangen (und auf Spam und Viren prüfen), Mails versenden (und signieren, sowie auf Spam und Viren prüfen) und wir können E-Mails abrufen. Nun wird es endlich Zeit, unsere Mailkonten einzurichten.

In den vorherigen Artikeln hatte ich jeweils beispielhaft die Inhalte der Konfigurationslisten gezeigt, die benötigt werden, um die einzelnen Komponenten (Postfix, Dovecot und OpenDKIM) startklar zu machen. Leider ist diese verteilte Einrichtung mit Hilfe von Listen sehr zeitraubend und fehleranfällig. Deshalb hatte ich mir überlegt, wie man das ganze etwas vereinfachen könnte: Dabei heraus gekommen ist "mailconf.phs".

mailconf.phs ist ein PHP-Script, das mit Hilfe einer einzigen Konfigurationdatei die ganzen Teillisten erzeugt. Mit einer relativ einfachen Syntax kann man so alles weitere abbilden und kann die Ausgangsinformationen zusammenhalten.

Um es nutzen zu können, sollte man es natürlich im ersten Schritt installieren. Es wird das PHP Commandline Interface (PHP-CLI) benötigt. Zudem solltet ihr euch Mercurial installieren, um mailconf.phs direkt aus dem Repository zu laden.

1
2
sudo apt-get update
sudo apt-get install php5-cli mercurial

Dann könnt ihr euch das Repository mit einem einfachen Clone-Befehl besorgen:

1
2
sudo hg clone https://hg.nhg.name/mailconf/
sudo hg clone https://hg.nhg.name/unchroot/

Danach solltet ihr euch als erstes natürlich die Datei "README" durchlesen. Schritt 1 und Schritt 2 sind bereits erledigt. Schritt 3 und Schritt 4 werde ich euch jetzt versuchen, etwas näher zu bringen.

1
2
3
4
5
6
README:

1.) Copy all mailconf.* files to a location that can not be accessed remotely
2.) Install https://hg.nhg.name/unchroot/
3.) Write configuration file which defines the content of the generated lists.
4.) Generate lists by calling: sudo php mailconf.phs <Configuration-File-Name>

Wie schon erwähnt, müsst ihr eine Konfigurationsdatei für mailconf.phs erstellen. Ich werde erst einmal versuchen, die Syntax zu erklären. Anschließend sehen wir uns dann das Beispiel aus der Datei "EXAMPLE" an.

Die Form der Konfigurationsdatei ist stark an "*.ini"-Dateien angelehnt. Es gibt immer einen Kopf, der mit eckigen Klammern eingeleitet wird und darunter die eigentlichen Einstellungen, wobei erst der Name der Einstellung, dann ein Gleichheitszeichen und dann der Wert folgt. Kommentare werden mit Rauten eingeleitet:

1
2
3
# Beispielkommentar
[bli]
bla = blub

Das erste, was wir konfigurieren sollten, sind natürlich die Domains, für die unser Mailserver zuständig sein soll. Dazu setzen wir einfach einen Kopf und schreiben dort den Namen der jeweiligen Domain hinein:

1
2
# definiert die Domain "example.com"
[example.com]

Wie wir im Artikel über Mailsignaturen mit OpenDKIM gesehen haben, kann einer Domain ein sogenannter Selektor zugewiesen sein, der angibt, welcher DKIM-Schlüssel für das Signieren von E-Mails verwendet werden soll. Diesen Selektor können wir an dieser Stelle den Domains zuweisen:

1
2
3
4
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

Neben den Domains müssen natürlich auch die eigentlichen E-Mail-Adressen definiert werden. Das machen wir, indem wir im Kopf einfach die Adresse selbst eintragen. Dabei stellt mailconf.phs automatisch sicher, dass nur Adressen verwendet werden, zu denen auch die entsprechende Domain definiert wurde:

1
2
3
4
5
6
7
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Addresse "root@example.com"
[root@example.com]

Mit einer Adresse kann man jedoch noch nicht allzu viel anfangen. Man muss sich entscheiden, ob es sich um eine Adresse handeln soll, die mit einer Mailbox verknüpft ist oder aber ob es eine reine Weiterleitung ist. Im folgenden Beispiel legen wir die Weiterleitung "root@example.com" an und die Mailbox "kenny@example.com". Mailboxen sind dadurch gekennzeichnet, dass sie ein Passwort besitzen:

1
2
3
4
5
6
7
8
9
10
11
12
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

Bei der Weiterleitung dürfte euch die Einstellung "inout" auffallen. Diese besagt, dass die dahinter stehende Mailbox zum einen die E-Mails der Weiterleitungsadresse empfängt und auch E-Mails im Namen der Weiterleitungsadresse versenden darf. Bei solchen Einstellungen prüft mailconf.phs automatisch, ob der Empfänger der Weiterleitung eine lokale Adresse ist. Falls das der Fall ist, wird zudem geprüft, ob die Empfängeradresse definiert wurde und ob es sich dabei um eine Mailbox handelt.
Anstelle von "inout" kann auch zwischen "in" und "out" getrennt werden. "in" heißt immer, dass Mails an den entsprechenden Account weitergeleitet werden. "out" heißt immer, dass Mails von dem entsprechenden Account verschickt werden dürfen. Es können pro Adresse auch mehrere "in", "out" und "inout" Angaben gemacht werden.

Was auch auffällig sein dürfte, ist die Form des Passworts des Accounts "kenny@example.com". Wir hatten uns in den letzten Artikeln dafür entschieden, dass Dovecot seine Passworte als Salted Hashes ablegt. Genau diese Schreibweise benötigen wir nun hier. Mit folgendem Befehl könnt ihr passende Passworte erzeugen:

1
doveadm pw -s SSHA256

Wir werden nun noch einen weiteren Account anlegen - und zwar einen reinen Versandaccount. Solche Accounts können nützlich sein, wenn z.B. technische Geräte E-Mails versenden sollen. Da diese Geräte keine Mails lesen können, sollten die Mails an solch eine Adresse natürlich an eine andere Mailbox weitergeleitet werden:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com

Die Mailboxen "kenny@example.com" und "submit@example.com" haben das gleiche Passwort - dank der Salted Hashes ist das jedoch nicht erkennbar. Zudem werden im Beispiel alle Mails für "submit@example.com" an "kenny@example.com" weitergeleitet.
Solltet ihr irgendwann wollen, dass die Mails für "submit@example.com" auch tatsächlich an diese Mailbox zugestellt werden, könnt ihr das mit einer Selbstreferenz ("in = *") erreichen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com
in       = *

Eine Selbstreferenz für das Versenden von E-Mails ("out = *") ist für Mailboxen jedoch nie nötig. Sie wird implit immer erstellt. Mit anderen Worten: Mailboxen dürfen immer E-Mails in ihrem eigenen Namen senden.

Nachdem wir nun also definiert haben, welche Adressen es gibt, stellt sich die Frage, wie wir bestimmen, welche Dateien erstellt werden und wohin sie geschrieben werden. Für dieses Thema gibt es den Konfigurationsblock. Er wird mit einem leeren Kopf gekennzeichnet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com
in       = *

# hier beginnt die Konfiguration:
[]

Dateien werden geschrieben, indem entsprechende Dateitrigger definiert werden. Dateitrigger beginnen immer mit dem Begriff "file.", gefolgt von dem Namen der Komponente, für die die Datei erstellt werden soll ("dovecot", "opendkim", "postfix") und der Einstellung, für die die Datei erzeugt werden soll. Die Liste der möglichen Trigger sieht aktuell wie folgt aus:

  • file.dovecot.passwdfile
  • file.opendkim.ExternalIgnoreList
  • file.opendkim.InternalHosts
  • file.opendkim.KeyTable
  • file.opendkim.SigningTable
  • file.postfix.smtpd_sender_login_maps
  • file.postfix.virtual_alias_maps
  • file.postfix.virtual_gid_maps
  • file.postfix.virtual_mailbox_domains
  • file.postfix.virtual_mailbox_maps
  • file.postfix.virtual_uid_maps

Zudem müssen wir immer eine User-ID und eine Group-ID angeben, mit der mailconf.phs laufen soll. Da wir hier Konfigurationsdateien schreiben, verhindern wir damit, dass wir uns wichtige Dateien zerschießen, bzw. nur Konfigurationsdateien schreiben, deren Schreibrechte wir entsprechend gesetzt haben.

Wenn wir also beispielsweise die Liste der Domains für Postfix erstellen lassen wollen, können wir das ganze so steuern (unter der Annahme, dass der Nutzer "mailconf" existiert und Schreibrechte für die Datei hat):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com
in       = *

# hier beginnt die Konfiguration:
[]
# wir schreiben die Postfix Domainliste
file.postfix.virtual_mailbox_domains = /etc/postfix/domains.conf

# wir arbeiten als Nutzer mailconf mit der Gruppe mailconf
uid = mailconf
gid = mailconf

Die Konfigurationsdateien lasst ihr dann mit folgendem Befehl erzeugen:

1
sudo php mailconf.phs <Dateiname>

Mit zwei weiteren Zeilen können wir die Liste der Mailboxen und die Liste der Aliasse schreiben lassen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com
in       = *

# hier beginnt die Konfiguration:
[]
# wir schreiben die Postfix Aliasliste
file.postfix.virtual_alias_maps      = /etc/postfix/aliases.conf
# wir schreiben die Postfix Domainliste
file.postfix.virtual_mailbox_domains = /etc/postfix/domains.conf
# wir schreiben die Postfix Mailboxliste
file.postfix.virtual_mailbox_maps    = /etc/postfix/mailboxes.conf

# wir arbeiten als Nutzer mailconf mit der Gruppe mailconf
uid = mailconf
gid = mailconf

Nunja. Zumindest fast. Einige der Dateitrigger benötigen weitere Parameter. Welche das sind, wird euch bei der Ausführung durch eine entsprechende Fehlermeldung mitgeteilt, wenn es sich um Pflichtparameter handelt. Parameter beginnen immer mit dem Begriff "param.", gefolgt von dem Namen der Komponente, für die die Datei erstellt werden soll ("dovecot", "opendkim", "postfix") und der Einstellung, für die die Datei erzeugt werden soll.

Im obigen Beispiel müssen wir dem Dateitrigger "file.postfix.virtual_mailbox_maps" mitteilen, wie der relative Pfad zum Maildir-Ordner heißt. Das machen wir über den Parameter "param.postfix.virtual_mailbox_maps":

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# definiert die Domain "example.com"
[example.com]
# definiert den Selektor der Domain "example.com"
selector = send2014

# definiert die Weiterleitung "root@example.com"
[root@example.com]
inout = kenny@example.com

# definiert die Mailbox "kenny@example.com"
[kenny@example.com]
password = {SSHA256}/ZdbEwfJtC1fSkuVkisIHGnSNyqhSJwgQvu2Hb2JoeiBC+lw

# definiert die Mailbox "submit@example.com"
[submit@example.com]
password = {SSHA256}gLNtzgEM6m6IacJ+goE8kARoUnx2WiviqXv9336/3lTfcY+y
in       = kenny@example.com
in       = *

# hier beginnt die Konfiguration:
[]
# wir schreiben die Postfix Aliasliste
file.postfix.virtual_alias_maps      = /etc/postfix/aliases.conf
# wir schreiben die Postfix Domainliste
file.postfix.virtual_mailbox_domains = /etc/postfix/domains.conf
# wir schreiben die Postfix Mailboxliste
file.postfix.virtual_mailbox_maps    = /etc/postfix/mailboxes.conf

# relativer Pfad zum Maildir einer Mailbox
param.postfix.virtual_mailbox_maps = Maildir/

# wir arbeiten als Nutzer mailconf mit der Gruppe mailconf
uid = mailconf
gid = mailconf

Nun könnt ihr die Konfigurationdateien erstellen lassen:

1
sudo php mailconf.phs <Dateiname>

In der Datei "EXAMPLE" könnt ihr euch sämtliche Dateitrigger mit ihren Pflichtparametern und ihren optionalen Parametern ansehen. Auch die Funktionsweise des Konfigurationsblocks ist dort noch einmal ein wenig ausführlicher beschrieben:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
# defines a domain
[example.com]

# defines the DKIM selector of that domain
selector = send2014

# defines an address
# defined addresses must be within a defined domain
[kenny@example.com]

# password of that address
# addresses with passwords are assumed to be mailboxes
password = test

# UID of that address
# only mailboxes need UIDs as these have to be owned by a system user
uid = mail_kenny

# implicitly a mailbox is always allowed to send and receive mails of itself
# inout = *

# GID of that address
# only mailboxes need GIDs as these have to be owned by a system user
gid = mail_kenny

# defines another address
[submit@example.com]

# password of that address
# addresses with passwords are assumed to be mailboxes
password = test

# mails sent to that address will be forwarded to an external address
in = submit@example.net

# mails sent to that address will also be forwarded to another internal mailbox
# that mailbox is also allowed to send mails on behalf of this address
inout = kenny@example.com

# whenver forwards are defined for a mailbox a forward to the mailbox itself
# has to be defined - this makes it possible to define send-only accounts
in = *

# implicitly a mailbox is always allowed to send mails on behalf of itself
# out = *

# defines yet another address
[postmaster@example.com]

# just a plain internal forward without send-privileges
in = kenny@example.com

# the empty bracket defines the configuration block
[]

# mailconf works as follows:
# Each file output format is implemented in a file
# "mailconf.<x>.phs". These files are triggered by
# defining the value "file.<x>" and assigning it an
# output file name. In addition these files may
# require additional configuration parameters which
# are defined with "param.<x>.<y>" whereby ".<y>" may
# be omitted depending on the output implementation
# (e.g. when only a single configuration parameter is
# required). Export files shall warn you when a
# mandatory configuration parameter has not been set.
#
# If you do not want to create a specific file then
# just comment out the corresponding "file.<x>" line.
# The corresponding "param.<x>.<y>" can stay intact.
# They will just be ignored.
#
# By specifying a "file.<x>" more that once that file
# will be generated several times (e.g. when one file
# is needed in different locations).

# dovecot configuration files
file.dovecot.passwdfile = /etc/dovecot/auth/accounts

# OpenDKIM configuration files
file.opendkim.ExternalIgnoreList = /etc/opendkim/trusted.conf
#file.opendkim.InternalHosts     = /etc/opendkim/trusted.conf
file.opendkim.KeyTable           = /etc/opendkim/keys.conf
file.opendkim.SigningTable       = /etc/opendkim/domains.conf

# Postfix configuration files
file.postfix.smtpd_sender_login_maps = /etc/postfix/logins.conf
file.postfix.virtual_alias_maps      = /etc/postfix/aliases.conf
file.postfix.virtual_gid_maps        = /etc/postfix/gids.conf
file.postfix.virtual_mailbox_domains = /etc/postfix/domains.conf
file.postfix.virtual_mailbox_maps    = /etc/postfix/mailboxes.conf
file.postfix.virtual_uid_maps        = /etc/postfix/uids.conf

# default uid for mailboxes (optional)
param.dovecot.passwdfile.uid = vmail

# default gid for mailboxes (optional)
param.dovecot.passwdfile.gid = vmail

# home path for mailboxes (optional)
# should match with Postfix virtual_mailbox_base
#param.dovecot.passwdfile.home = /srv/mailusers/

# value of userdb_mail (optional)
# default value: maildir:~/Maildir
#param.dovecot.passwdfile.userdb_mail = maildir:~/Maildir

# path to DKIM private keys (mandatory)
param.opendkim.KeyTable = /etc/opendkim/keys/

# value of Postfix home_mailbox (mandatory)
# default value: Maildir/
param.postfix.virtual_mailbox_maps = Maildir/

# default uid for mailboxes (mandatory)
param.postfix.virtual_uid_maps = vmail

# default gid for mailboxes (mandatory)
param.postfix.virtual_gid_maps = vmail

# UID and GID of mailconf.phs process (mandatory)
uid = mailconf
gid = mailconf

Auch wenn ich das Thema gern vermeiden würde, da es schwer zu vermitteln ist, muss ich es leider anschneiden: Auch Mailboxen haben eine User-ID und eine Group-ID. Das sind der Nutzer und die Gruppe, unter denen die Maildateien abgelegt werden.

Unser Setup sieht bisher vor, dass Postfix statisch den Nutzer "vmail" samt der Gruppe "vmail" verwendet, um die Maildateien zu schreiben und passende Ordner anzulegen. Im späteren Verlauf will man aber jedoch vielleicht, dass die Maildateien jeder Mailbox unter einem eigenen Account abgelegt werden. Dazu muss für jede definierte Mailbox ("kenny@example.com", "submit@example.com", etc.) eine UID und GID angegeben werden. Für Mailboxen, bei denen das vergessen wurde, wird die Default-UID und die Default-GID verwendet, die im Konfigurationsblock angegeben werden.

Ich habe es bei mir z.B. so gemacht, dass bei Mailadressen der Form "<name>@<domain>" der zugehörige Systemnutzer immer "mail_<name>" heißt (also bei "kenny@example.com" z.B. "mail_kenny").

Solltet ihr euch bei dem Thema Zugriffsrechte auf Nutzer- und Gruppenebene nicht auskennen, muss ich euch dringend anraten, euch mit diesem Thema auseinanderzusetzen. Damit steht und fällt die Sicherheit der von euch betriebenen Server.

Hoffentlich konnte ich euch die Funktionsweise und Notation von mailconf.phs ein wenig näher bringen. Sollte euch die Metasprache von mailconf.phs nicht zusagen, könnt ihr natürlich auch einfach wie bisher die Dateien einzeln per Hand erstellen. Jetzt bei den Beispielen mag es sehr überborden aussehen. Je mehr Domains und Mailadressen jedoch hinzukommen, desto nützlicher ist das Tool. Mir persönlich ist das Script jedenfalls eine große Hilfe bei anfallenden Änderungen im laufenden Betrieb.

Konfigurierende Grüße, Kenny

0 Kommentare » Schreibe einen Kommentar

  1. Moin moin,

    beim clonen der Mercurial Repositories bekomme ich folgende Fehlermeldung:

    root@liebich:~/Download# hg clone https://hg.nhg.name/unchroot/
    abort: hg.nhg.name certificate error: certificate is for nix.li, calc.pw, *.calc.pw, coltishware.com, *.coltishware.com, coltishware.net, *.coltishware.net, niehage.name, *.niehage.name, *.nix.li, nix.lu, *.nix.lu, weizensa.at, *.weizensa.at, weizenspr.eu, *.weizenspr.eu
    (configure hostfingerprint 7d:78:b7:25:02:af:7d:de:6c:15:03:1f:16:43:99:cf:fa:9b:db:62 or use --insecure to connect insecurely)

    Sieht danach aus, dass irgendwas mit dem Zertifikat nicht stimmt.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.