dkimproxy und Key mismatch

[HZB]

Ich habs jetzt mit meinem verglichen. Bei mir steht folgendes:

Code: Alles auswählen

default._domainkey.meinedomain.com. 2994 IN TXT "v=DKIM1\; k=rsa\; " "p=MIGfMA0..."

Bei Dir:

Code: Alles auswählen

default._domainkey.simonszu.de. 3600 IN TXT     "v=DKIM1\; k=rsa\; p=MIGfMA0...."

Probier mal nach k=rsa; ein Hochkomma und vor dem p= noch eines

[simonszu]

Habe ich mal gemacht, ich erhoffe mir aber nicht viel. Laut http://kb.kerio.com/product/kerio-conne ... -1483.html (ganz unten bei BIND) ist das wohl ne Syntax, die es erlaubt, den Key, bzw. allgemein Multiline-TXT-Records auf ein paar mehr Zeilen zu splitten. Ich habe die Domain bei INWX, die nutzen mWn aber PowerDNS. Wenngleich mit im Webfrontend nach dem k=rsa tatsächlich ein Zeilenumbruch angezeigt wird, das scheint aber nur darstellungsbedingt zu sein, wegen des langen Keys. Im Edit-Modus des Records ist nämlich wieder alles in einer Zeile.

[HZB]

Mein Fehler. Nicht das einfache ' Hochkomma sondern " Anführungszeichen.

[simonszu]

Hat leider alles nichts gebracht. Ich habe jetzt noch mal den Record editiert, und peinlich genau drauf geachtet, dass da exakt das drin steht, was in http://dkimproxy.sourceforge.net/usage.html beschrieben steht. Also

Code: Alles auswählen

k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCBuVStHqwOmbBS6gv09KrHzOeQ9v0Y8t2XGvVxAR6Cb8G6NQyf1C2bj2WuSjvSkEZu+xu817XZVZfM4RWfN83vYIdSV47dG6ctjQsMxvhtLPmS+uhKS6MG9KeN4fdTrXNOZNwp6nYEQciVS03jv6C3a3FQStFCGDsKcpKkz4ePwIDAQAB

Mal gucken, ob's hilft. Denn trotz der Hochkommata bzw. Anführungszeichen meldeten die Tools immer noch, dass kein Key vorhanden wäre.

[HZB]

Nein stimmt leider immer noch nicht:

Code: Alles auswählen

dig -t txt default._domainkey.simonszu.de.

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> -t txt default._domainkey.simonszu                                                                                                              .de.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52071
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;default._domainkey.simonszu.de.        IN      TXT

;; ANSWER SECTION:
default._domainkey.simonszu.de. 3600 IN TXT     "k=rsa\; t=s\; p=MIGfMA0GCSqGSIb                                                                                                              3DQEBAQUAA4GNADCBiQKBgQDCBuVStHqwOmbBS6gv09KrHzOeQ9v0Y8t2XGvVxAR6Cb8G6NQyf1C2bj2                                                                                                              WuSjvSkEZu+xu817XZVZfM4RWfN83vYIdSV47dG6ctjQsMxvhtLPmS+uhKS6MG9KeN4fdTrXNOZNwp6n                                                                                                              YEQciVS03jv6C3a3FQStFCGDsKcpKkz4ePwIDAQAB"

Kein v=DKIM1 und keine Hochkomma.

[simonszu]

Das ist richtig. Das v=DKIM1 und die Hochkommata habe ich rausgenommen, als klar war, dass die DKIM-Validatoren im Internet _mit_ diesem Tag und den Hochkommata bzw. Anführungszeichen den Key nicht gefunden haben. Immerhin steht der Record, so wie er jetzt gerade im DNS steht, genau so in der Dokumentation von dkimproxy.

Ich habe gerade noch mal den Prozess mit dkimvalidator.com geprüft, und der kommt zu dem Schluss:

DKIM Information:

DKIM Signature


Message contains this DKIM Signature:
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=tharan.simonszu.de; h=
mime-version:frommessage-id:subject:to:content-type; s=
default; bh=ti3MGZZ3obJf8PQdoYdQDG2boeo=; b=ek6Q2yHAJSIxbLUlbTwg
eY5yHRzE1DAN5rDWBOH6iM+QR7w4LGIyJ10COJeKKWB1j+wZ6vnd6pd7UAosWk7A
OupGg/4xXVKFsi1odbURl/Zrflf+KxVCGvpMUh5tEHGi1Gn8rBDC1ZSxp19hN11U
xV1eU6bE7dKaabb73oxcGpI=


Signature Information:
v= Version: 1
a= Algorithm: rsa-sha1
c= Method: simple
d= Domain: tharan.simonszu.de
s= Selector: default
q= Protocol:
bh= ti3MGZZ3obJf8PQdoYdQDG2boeo=
h= Signed Headers: mime-version:frommessage-id:subject:to:content-type
b= Data: ek6Q2yHAJSIxbLUlbTwg
eY5yHRzE1DAN5rDWBOH6iM+QR7w4LGIyJ10COJeKKWB1j+wZ6vnd6pd7UAosWk7A
OupGg/4xXVKFsi1odbURl/Zrflf+KxVCGvpMUh5tEHGi1Gn8rBDC1ZSxp19hN11U
xV1eU6bE7dKaabb73oxcGpI=
Public Key DNS Lookup


Building DNS Query for default._domainkey.tharan.simonszu.de
Retrieved this publickey from DNS:
Validating Signature


result = invalid
Details: public key: not available

Aus irgendeinem Grund schickt mein Server die Mails also immer noch mit falschem Hostnamen raus. Ich habe keine Ahnung, wieso das so ist. Die Config vom dkimproxy kennst du ja schon, hier ist mal die Config von meinem OpenSMTPd

Code: Alles auswählen

# This is the smtpd server system-wide configuration file.
# See smtpd.conf(5) for more information.

# Load keys and certs for TLS
pki simonszu.de key "/etc/ssl/private/mail.key"
pki simonszu.de certificate "/etc/ssl/certs/mail.crt"

### INTERFACES LISTEN DIRECTIVES ###
# Listen on localhost
listen on localhost

# Listen on the port where dkimproxy will hand in dkim-ed mail and tag them as DKIM_OUT
listen on localhost port 10029 tag DKIM_OUT

# Listen on plain SMTP port 25
# Usually used for other MXes submitting their mails to us
listen on eth0 port 25 hostname tharan.simonszu.de tls pki simonszu.de

# Listen on SMTP with TLS port 587
# Usually used by our mailclients to connect with auth
listen on eth0 port 587 hostname tharan.simonszu.de tls-require pki simonszu.de auth mask-source

### VIRTUAL STUFF ###
# If you edit the file, you have to run "smtpctl update table aliases"
table valiases file:/etc/mail/valiases
table vdomains file:/etc/mail/vdomains
table aliases file:/etc/aliases

### RULES FOR ACCEPTING MAILS ###
# This catches from external submitted mails to any of our <valiases> and <vdomains> which are routed as these files say
# deliver to mbox is obsolete since the catchall in valiases forwards them to gmail but the syntax requires it anyways
accept from any for domain <vdomains> virtual <valiases> deliver to mbox

# This catches all mails (local generated or submitted via TLS-auth) wich are addressed to any of our local <valiases>
# They are delivered like the rules in <valiases> say
accept from local for local virtual <valiases> deliver to mbox

# This catches all local generated mails (or submitted via TLS-auth) which are not addressed to any of <valiases>
# They are relayed via DNS resolving and MX
# The from local is default and can be omitted but it is here for clearness
# Mails coming from dkimproxy are tagged DKIM_OUT. Only accept these
accept tagged DKIM_OUT from local for any relay
# Send un-dkim-ed mails to dkimproxy
accept from local for any relay via smtp://127.0.0.1:10028
# Relay any local generated mails
# accept from local for any relay


# Any mails from external sources which are also routed to external sources are not catched at all
# They are denied for spam prevention



### SNIPPETS FOR SPAMASSASSIN ###
# Listen on port 10026, where spamassassin dumps its checked mails and tag them
#listen on lo port 10026 tag Filtered
# Accept every external mail from us and forward them to spamassassin
#accept from any for domain "simonszu.de" relay via "smtp://127.0.0.1:10025"
# Accept filtered mails from spamassassin for us and deliver it
# accept tagged Filtered for any alias <aliases> deliver to mbox

In meiner /etc/mailname steht nur simonszu.de
Im MX-Record für die Domain steht tatsächlich "smtp.simonszu.de". Könnte ich mal ändern, ist aber eigentlich egal, weil ich ein Wildcard-A-Record, bzw. AAAA-Record habe.
Joa, und dann halt noch die /etc/hosts,

Code: Alles auswählen

127.0.0.1       localhost
127.0.1.1       tharan.simonszu.de    simonszu.de    tharan

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Das sind jetzt alle Dateien, die ich eben so zusammengegreppt habe, wo der String 'tharan' drin vorkommt. Die TLS-Keys für den OpenSMTPd habe ich auch nur mit 'openssl genrsa' erstellt, da sollte also auch kein Hostname oder ähnliches eincodiert sein.

[HZB]

Dann kann es nur noch am Schlüssel liegen. Generiere Dir einen neuen, aber versuchs vielleicht mal opendkim-genkey:

Code: Alles auswählen

opendkim-genkey -s default  -d simonszu.de

[simonszu]

Wieder ein Fortschritt. Ich habe die Keys mit opendkim-Testkey generieren lassen, und den Record upgedatet, sowie den dkimproxy neu gestartet, um den neuen Key einzulesen. Jetzt ist der Public Key wieder auffindbar, aber die Validatoren meckern wieder wegen key mismatch. Also stehe ich wieder ganz am Anfang.

Code: Alles auswählen

DKIM Information:

DKIM Signature


Message contains this DKIM Signature:
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=simonszu.de; h=mime-version
	:from:date:message-id:subject:to:content-type; s=default; bh=3gQ
	Q8wA8SviSLWSaJVKF+OJo7HE=; b=ojJppRW04OmKboJtD93fxskDE5C/tIp1hFZ
	eUZp38jTuAz1iteuAvx3mHAfcTrRKiPcIU+efkgFHRt08XaFFdVtecm7veeRWkXy
	YAUcGS3AmpuvUQeDGZROnYnQ7W5D4pWfda8OH686rbAzpv9GARPP40SOPNPflwD2
	LsTubp+s=


Signature Information:
v= Version:         1
a= Algorithm:       rsa-sha1
c= Method:          simple
d= Domain:          simonszu.de
s= Selector:        default
q= Protocol:        
bh=                 3gQ
	Q8wA8SviSLWSaJVKF+OJo7HE=
h= Signed Headers:  mime-version
	:from:date:message-id:subject:to:content-type
b= Data:            ojJppRW04OmKboJtD93fxskDE5C/tIp1hFZ
	eUZp38jTuAz1iteuAvx3mHAfcTrRKiPcIU+efkgFHRt08XaFFdVtecm7veeRWkXy
	YAUcGS3AmpuvUQeDGZROnYnQ7W5D4pWfda8OH686rbAzpv9GARPP40SOPNPflwD2
	LsTubp+s=
Public Key DNS Lookup


Building DNS Query for default._domainkey.simonszu.de
Retrieved this publickey from DNS: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCphDkASrfcHfB+V1MJAf/uZQYG9YzSrUl6g2V47dZrgpF1TSG8ZyP9f8RVMyt7Q/67XLQxgWPvbcpnCakuHO88A5UE5xG3Ds+Dev6r/w70OnOvHOui4Y1egUJgX4pWyiaLwozRf54RtudjpH0/Ydm7DDIXtC3eE5QZbVi9uwqx3wIDAQAB
Validating Signature


result = fail
Details: bad RSA signature

Immerhin hat er jetzt den richtigen Signee drin - und nicht mehr den tharan-Hostnamen.

[HZB]

opendkim-genky generiert ja 2 Keys den public und den private.
Nur um sicher zu gehen. Hast Du den private Key auch nach /etc/dkimproxy/keys/private.key kopiert ?

[simonszu]

...mit dem kleinen Unterschied, dass mein opendkim-genkey einen private-key und direkt ein txt-File mit dem gesamten Record in BIND-Syntax generiert hat.
Ja, ich habe den private.key in das Verzeichnis gepackt (und den dkimproxy danach neu gestartet), und die Payload aus besagtem txt-File in das Webfrontend meines Registrars gekippt.
Nur mal rein interessehalber: Wie sollte der Output von opendkim-testkey aussehen, wenn alles passt? Momentan liefert er nämlich einfach gar keinen Output - was ja eigentlich nicht schlecht scheint, im Vergleich zu früher, wo er gejammert hat, dass die Keys nicht matchen.
Vielleicht passen die Keys ja tatsächlich, es stimmt nur was nit mit der RSA-Signatur.
.
.
.
Hmm, okay. Ich habe noch mal den opendkim-testkey mit maximalem -v ausprobiert. Nun habe ich einen Output:

Code: Alles auswählen

 # opendkim-testkey -d simonszu.de -k private.key -s default -vvvvv
opendkim-testkey: key loaded from private.key
opendkim-testkey: checking key 'default._domainkey.simonszu.de'
opendkim-testkey: key not secure
opendkim-testkey: key OK

Ich glaube, ich bin kurz davor, alles richtig zu haben - bzw, eigentlich kann ich das ja tatsächlich so lassen. Aber wenn ich das mache, dann eigentlich richtig.

[HZB]

Kein Output ist schon mal gut.
Das Key not secure ist normal wenn Du kein DNSSEC hast.

Also eigentlich schaut das jetzt gut aus.

[simonszu]

Yeah, super. Dann lass ich das jetzt erstmal so, und kümmere mich nächstes Jahr um dnssec oder so. Von Crypto habe ich jetzt erstmal die Schnauze voll.
Vielen, vielen Dank für deine Hilfe, ich glaube, alleine würd ich jetzt immer noch rumkrebsen, weil ich nie auf opendkim-genkey gekommen wäre.

[simonszu]

Für die Nachwelt: Das Problem ist gelöst.
Debian setzt in der /etc/default/dkimproxy einen Eintrag auf einen private.key, der unterhalb von /var/lib/dkimproxy liegt. Da dieser Key dkimproxy vom Initscript als Argument mitgegeben wird, nimmt dkimproxy bevorzugt diesen Key, auch wenn in der dkimproxy_out.conf was anderes steht.
Das perfide ist: Dieses Setting in der /etc/default/dkimproxy ist standardmäßig auskommentiert, allerdings geht das Initscript dann hin, und setzt einen Standardwert. Man muss also explizit im default-File auf seinen manuell erzeugten Key verweisen, den man auch in der dkimproxy_out.conf stehen hat, oder man freut sich einfach, dass dpkg bei der installation von dkimproxy bereits ein Keypair erzeugt, und muss nur darauf achten, dass die dkimproxy_out.conf auf dieses Keypair verweist.