OpenDKIM Milter works, DNSSec enabled but opendkim-testkey key not secure

S

sjohn

I am trying to setup my second mail server from scratch and writing a howto based on the Debian howto by linuxbabe. I've managed to get everything working up the opendkim and I have even managed to get opendkim to sign the emails. It all works but opendkim-testkey still stays it's not secure. I used postfix and dovecot from ports but everything else from packages. I have tried both opendkim and opendkim-devel and and now on the devel version. I know it's not required to be secure but wondering why it isn't? I ran the exact same command on the Debian machine I put up for the test run and it says secure. Since I am writing a howto and probably will scrap the first install I am not trying to keep the server id secret. Tried fixing file permissions and dnssec with unbound. I am using unbound not local_unbound.

My write up so far is at ...

FreeBSD Email Setup #1 - 06 SPF DMARC And DKIM

Growing Figs in Zone 6a
okfigs.com okfigs.com
Code: 
VERSION="14.2-RELEASE"

@mx.okfigs.com:~# opendkim-testkey -d okbsd.com -s CRHdAnOqqitUaWRuNkHLdIpbgw76 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com'
opendkim-testkey: key secure
opendkim-testkey: key OK
On FreeBSD /etc/rc.conf
Code: 
milteropendkim_enable="YES"
milteropendkim_cfgfile="/usr/local/etc/opendkim/opendkim.conf"
milteropendkim_uid="opendkim"
milteropendkim_gid="opendkim"
milteropendkim_socket="local:/var/spool/postfix/opendkim/opendkim.sock"
milteropendkim_socket_perms="0770"
Code: 
@okbsd.com:/usr/local/etc/opendkim# opendkim-testkey -d okbsd.com -s CRHdAnOqqitUaWRuNkHLdIpbgw76 -vvv
opendkim-testkey: checking key 'CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com'
opendkim-testkey: key not secure
opendkim-testkey: key OK

@okbsd.com:/usr/local/etc/unbound# dig @127.0.0.1 okbsd.com a +dnssec

; <<>> DiG 9.20.8 <<>> @127.0.0.1 okbsd.com a +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64347
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;okbsd.com.                     IN      A

;; ANSWER SECTION:
okbsd.com.              600     IN      A       147.135.65.97
okbsd.com.              600     IN      RRSIG   A 13 2 1799 20250522000000 20250501000000 4723 okbsd.com. wlDSZXSfAsshstsmxdC1+U8yZL4B3ie1I7e/C3JrHAkJGVs/buUsCZMk ia11WySoKsC4F1ShW4pz/LGrBMF+0g==

;; Query time: 201 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed May 14 14:47:41 PDT 2025
;; MSG SIZE  rcvd: 159
For this section of the howto I have installed... though I am not sure why or how to use ca_root_nss, I read some post that said it was needed
Code: 
pkg install py311-spf-engine
pkg install ca_root_nss
pkg install chrony
pkg install opendkim
The other cause mentioned is that the keys are not secure and only readable by opendkim
Code: 
grep opendkim /etc/passwd /etc/group
/etc/passwd opendkim:*:118:118:User &:/var/run/opendkim:/usr/sbin/nologin
/etc/group opendkim:*:118: postfix

@okbsd.com:/usr/local/etc# ls -ld opendkim
drwxr-xr-x  3 root wheel 11 May 13 16:37 opendkim/

@okbsd.com:/usr/local/etc/opendkim# ls -l
total 53
-rw-r--r--  1 root     wheel        3 May 13 15:07 bodylengthdb.cfg
drwx------  3 opendkim opendkim     3 May 13 16:37 keys/
-rw-r--r--  1 root     wheel      165 May 13 16:48 keytable
-rw-r--r--  1 root     wheel     3329 May 13 15:10 opendkim.conf
-rw-r--r--  1 root     wheel    22671 May 13 12:26 opendkim.conf.bak
-rw-r--r--  1 root     wheel    22671 May 13 12:26 opendkim.conf.bak2
-rw-r--r--  1 root     wheel    21800 Apr 16 23:21 opendkim.conf.sample
-rw-r--r--  1 root     wheel      209 May 13 15:07 signingtable
-rw-r--r--  1 root     wheel       48 May 13 15:07 trustedhosts

@okbsd.com:/usr/local/etc/opendkim/keys# ls -l
total 1
drwx------  2 opendkim opendkim 4 May 13 15:07 okbsd.com/
ls -l keys
-rw-------  1 opendkim opendkim 1704 May 13 15:07 CRHdAnOqqitUaWRuNkHLdIpbgw76.private
-rw-------  1 opendkim opendkim  537 May 13 15:07 CRHdAnOqqitUaWRuNkHLdIpbgw76.txt
So the files are only readable by opendkim user.

As I mentioned milter-opendkim starts and appends the DKIM signature to outgoing mail, just wonder why the testkey shows not secure?

Any help is much appreciated.
 
Last edited by a moderator:
First: keep in mind that mixing ports and packages isn't always a good idea and could result in problems along the way.

There are basically 2 reasons why a key would be considered insecure... first are the file permissions, second is the trust factor; keys are usually signed by an authority and if that authority can't be verified then obviously the key isn't fully secure. Doesn't DKIM rely on a TXT record besides DNSSEC?
 
Yes, DKIM relies on a TXT record ... doing a dig from both machines, I don't see any differences that really jump out at me. I did look through the code on Debian, then did a make in mail/opendkim-devel release directory ... ran grep 'not secure' in both which traces back to DKIM_DNSSEC_INSECURE from ubdata->ubd_result ..
and I don't see anything to do with file permissions. So ran dig again on both machines and must be something in the result that dig isn't showing. Did a make in ports/dns/unbound. Couldn't figure out much from that so thought maybe it local of the config or root.key or root.hints.
Code: 
#define CONFIGFILE "/usr/local/etc/unbound/unbound.conf"
#define ROOT_ANCHOR_FILE "/usr/local/etc/unbound/root.key"
unbound.h: * root hints or pointing to a local authoritative dns server.
unbound.h: *    For root hints it should be set to true.
I noticed one difference the /etc/unbound there are on debian
Code: 
-rw------- 1 root root 2484 Apr  4 21:08 unbound_control.key
-rw-r----- 1 root root 1501 Apr  4 21:08 unbound_control.pem
-rw------- 1 root root 2484 Apr  4 21:08 unbound_server.key
-rw-r----- 1 root root 1549 Apr  4 21:08 unbound_server.pem
None of these in FreeBSD.
Ah I ran unbound-control and now I have them ... enabled unbound control in unbound.conf and still opendkim key not secure :(

Also I haven't defined any of the auth-zone section in the FreeBSD unbound.conf but I have these...
Code: 
        root-hints: "/usr/local/etc/unbound/root.hints"
        auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
        # dnssec-validation: yes # this causes unbound to fail to restart and seems to be a directive for bind
        val-log-level: 2
Do you think I need to post my unbound.conf?
Code: 
@okbsd.com:~# dig @127.0.0.1 CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com +dnssec

; <<>> DiG 9.20.8 <<>> @127.0.0.1 CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13105
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com. IN A

;; AUTHORITY SECTION:
okbsd.com.              600     IN      SOA     dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1747094233 43200 3600 604800 3601
okbsd.com.              600     IN      RRSIG   SOA 13 2 3601 20250522000000 20250501000000 4723 okbsd.com. pj2ZR3MT6W0VScxnGJwO3Jw0LfWtw3IsPsdAMW+1Ul8WejjyqCUixFKJ jgj0GEMWNRlB9zCmt4HIin2227V7vg==
CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com. 600 IN NSEC _autodiscover._tcp.okbsd.com. TXT RRSIG NSEC
CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com. 600 IN RRSIG NSEC 13 4 3601 20250522000000 20250501000000 4723 okbsd.com. Cs0EViXH/eJ1vRS3Kr7IcAE0dw9p771DFtnI4PzNoaAGOjD1cIL/wIs3 QAjGft0j/LeDVj4kTV1mpwiQ/s5PeA==

;; Query time: 869 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu May 15 08:19:31 PDT 2025
;; MSG SIZE  rcvd: 408
At this point I am kind of thinking it's a problem with the port/pkg of unbound or opendkim, possibly looking for files or settings in an unusual location which doesn't affect it's function just reporting, erroneously, that the 'key is not secure'. I did have a similar problem on Debian until I used /etc/dkimkeys directory for the keys and keytable signingtable and trustedhosts ... but it was trying a lot of things so changing the directory may not have been what fixed it, I did try using that directory first when I setup opendkim on FreeBSD.

Interesting testing both keys from the debian server shows keys secure and testing both keys on FreeBSD show keys not secure. So it's either a configuration issue, which I sort of just copied the configs from debian and adapted or it's a pkg issue.

Again thanks for any help!
 
What is the point of allowing key files to be written? Sendmail does not like that (I do not use Postfix, still not even DNSsec). All my .key, .cert and .pem files are read-only (400).
 
Good point, changed that, still same result. I don't think postfix ever touches the opendkim keys it just connects through the socket.
I removed pkg unbound and pkg opendkim-devel and recompiled them from ports using what was enabled on debian as a guide, again everything works except the same result of keys not secure.

I'll give up and move on for now as it doesn't seem to affect the function, and I'll check back here later to see if anyone has more ideas. Thanks
 
In your opendkim.conf do you have a line like:
TrustAnchorFile /etc/unbound/root.key?

... assuming your opendkim has unbound option enabled, which I think is the default when installing from packages, but you can check via:
Bash: 
# pkg info opendkim | grep UNBOUND
        UNBOUND        : on
#

Also this snippet from the opendkim-testkey() manual page says:
NOTES
The test program will also complain if a private key file is readable
by anyone other than the user executing the program.
Click to expand...
(although admittedly it doesn't seem to have any effect when I test as root with files owned by 'sendmail')

So following vienuolis' advice to set the key/cert permissions to 0400 ( -r--------), if the files are owned by another non-root user you might have to test like this:
su -m KEY-FILE-OWNING-USER -c '/usr/local/sbin/opendkim-testkey -d DOMAIN -s SELECTOR -vvv -x PATH-TO-CONFIG-FILE'

Also throwing the -x PATH-TO-CONFIG-FILE in there just in case your opendkim.conf file isn't in the default location of /usr/local/etc/opendkim.conf


Above help based on looking at source code to opendkim but also this helpful serverfault post
 
pkg info opendkim-devel | grep UNBOUND
UNBOUND : on

TrustAnchorFile /usr/local/etc/unbound/root.key

opendkim-testkey -d okbsd.com -s CRHdAnOqqitUaWRuNkHLdIpbgw76 -vvv
opendkim-testkey: checking key 'CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com'
opendkim-testkey: key not secure
opendkim-testkey: key OK

su -m opendkim -c 'opendkim-testkey -d okbsd.com -s CRHdAnOqqitUaWRuNkHLdIpbgw76 -vvv -x /usr/local/etc/mail/opendkim.conf'
opendkim-testkey: checking key 'CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com'
opendkim-testkey: key secure
opendkim-testkey: key OK

opendkim-testkey -d okbsd.com -s CRHdAnOqqitUaWRuNkHLdIpbgw76 -vvv -x /usr/local/etc/mail/opendkim.conf
opendkim-testkey: checking key 'CRHdAnOqqitUaWRuNkHLdIpbgw76._domainkey.okbsd.com'
opendkim-testkey: key secure
opendkim-testkey: key OK

Hmmm interesting, if I include the -x and the full filepath it works, apparently the default location for opendkim.conf is /usr/local/etc/mail/opendkim.conf
so I change to that .. my keys and keytable etc files are under /etc/dkimkeys/files/keys/domain.tld/*.* so it doesn't matter where I put opendkim.conf it says not secure
unless I specify -x and the <path>/opendkim.conf either as root or user opendkim both will reply secure no matter the location.

So modify I'll the test command in my howto ... thanks!
 
when the config is used then it will know where the trust anchor file is
unbound lib will fail to validate dnssec without the trustanchor data (is like the CA files for a browser). dkim will init the lib with data from the trust anchor file.
you can test with
/usr/local/sbin/unbound-host -D -v -t txt $SELECTOR._domainkey.$DOMAIN

when file permissions are bad the error is slightly different (%s: key %s not secure) instead of (%s: key not secure) for dnssec problems
 
You must log in or register to reply here.
Back
Top