Getting Domainkeys, dkim, and SMTP-AUTH/TLS to play nicely together in sendmail 8.13.8
in [Sendmail]
|
Prev: Getting Domainkeys, dkim, and SMTP-AUTH/TLS to play nicely togetherin sendmail 8.13.8
Next: folded headers
From: Bruce Esquibel on 16 Apr 2010 15:58 Don Levey <Don_CMS(a)the-leveys.us> wrote: > STARTTLS=server: file /var/db/domainkeys/mail.key.pem unsafe: > permission denied > When I telnet to the server, port 587, and issue an EHLO, I see neither > AUTH nor TLS in the response. > The sendmail.mc file contains the line: > define(`localCERT',`/ver/db/domainkeys/mail.key.pem')dnl Unless you made a typo with the post, note in the sendmail.mc you called /var/db /ver/db. -bruce bje(a)ripco.com
From: mikea on 16 Apr 2010 16:10 Don Levey <Don_CMS(a)the-leveys.us> wrote in <hqadtp$5ru$1(a)news.eternal-september.org>: > A while back I struggled to get Domainkeys and DKIM to work properly on > my little home server. While I'm sure they weren't necessary in a > strict sense, it not only enabled me to learn about the technology but > allowed for more of a verification of the email coming from my server. > > And so this week I figured: "Hey, this has been working without a > problem for a while; it must be time to screw with something else." > Hence my effort to enable SMTP submissions over port 587. At the very > least, with some ISPs blocking traffic to port 25, this seemed to be a > good idea (as well as providing a better method for sending email using > my server from outside my home LAN). > > I've read a number of write-ups of SMTP AUTH, including the information > at sendmail.org. I've run into a snag, however, with the .pem > certificate that is used for the DK stuff. The conventional wisdom > seems to be to run domainkeys/dkim as a user other than root, and a .pem > certificate is required. Therefore, to get this to run properly, the > permissions on the certificate need to me 600 or 400, owned by this user. > > All well and good so far, except that STARTTLS doesn't like this: > > STARTTLS=server: file /var/db/domainkeys/mail.key.pem unsafe: > permission denied > > When I telnet to the server, port 587, and issue an EHLO, I see neither > AUTH nor TLS in the response. > > The sendmail.mc file contains the line: > > define(`localCERT',`/ver/db/domainkeys/mail.key.pem')dnl > > So if there's a different line I can add to indicate to TLS/AUTH that it > should use a different cert (or, rather, the same one copied to a > different location with different permissions...) I don't know it. > > Anyone ever run into this before? What are the group and owner of /var/db/domainkeys/mail.key.pem? What is the file's mode? What should they be? Looks like TLS_SAFE_F is returning FALSE because a call to safefile is returning non-zero, which happens with group and/or owner and/or mode problems. Sometimes it's just that the file is writable by folks who sendmail thinks shouldn't be able to write to it. -- Mike Andrews, W5EGO mikea(a)mikea.ath.cx Tired old sysadmin
From: Bruce Esquibel on 16 Apr 2010 18:37 Don Levey <Don_CMS(a)the-leveys.us> wrote: > The 'domainkeys' user is the one created to run domainkeys and dkim, and > they work with the file as is. However, from what I can tell, sendmail > sees that the file isn't owned by the sendmail user (which appears to be > root) and complains. The file itself isn't writable, though, as shown > above. You know, maybe it's different from what we're using (dkim-filter) but I think you have something mixed up... > The sendmail.mc file contains the line: > > define(localCERT',/ver/db/domainkeys/mail.key.pem')dnl I don't think the sendmail STARTTLS has anything to do with the key for the dkim, actually I'm not even sure what "localCERT" is up there. I mean with us, the sendmail.mc has these lines... define('confCACERT_PATH', '/etc/mail/certs') define('confCACERT','/etc/mail/certs/sf_issuing.crt') define('confSERVER_CERT','/etc/mail/certs/email.ripco.com.crt') define('confSERVER_KEY','/etc/mail/certs/server.key') for all the TLS stuff, the only line in it for the dkim is: INPUT_MAIL_FILTER('dkim-filter', 'S=inet:8888(a)localhost') I don't think the key for dkim needs to be told to sendmail at all, dkim runs as a daemon, separate from the sendmail process. I mean maybe you are trying to reuse the same key/cert but I think that is the problem in itself. -bruce bje(a)ripco.com
From: Bruce Esquibel on 20 Apr 2010 11:41
Don Levey <Don_CMS(a)the-leveys.us> wrote: > That didn't do it either - but now I get a different error: > SSL_CTX_use_PrivateKey_file(/var/db/starttls/mail.key.pem) failed > I don't see additional information as to why it failed, though. The > file itself is set at 400, owned by root. Everything I've seen via > Google so far suggests a permissions issue, though. Any ideas? Not permissions this time. That error, if I remember correctly has something to do with the format of the key, maybe with rsa vs. des. Thing is, how did you generate the key to begin with? With sendmail you need both a cert and key defined. I think the dkim just uses a key to validate/generate the headers from the public key used in the DNS entry for the machine. With sendmail this command line I think is the standard... openssl req -new -x509 -keyout mail.key.pem -out mail.cert.pem -days 365 and stick the two files made into your /var/db/starttls directory. With the sendmail.mc add these in: define('confCACERT_PATH','/var/db/starttls') define('confSERVER_CERT','/var/db/starttls/mail.cert.pem') define('confSERVER_KEY','/var/db/starttls/mail.key.pem') (note I can't print the leading ' (the one above tab) on this terminal.) I'm just saying what dkim is using I don't think is compatable with what sendmail is expecting. My advice is dump the dkim stuff for now, get the STARTTLS stuff working and after, go back to getting dkim to work. Again, I just don't think the key(s) each program is using can be re-used for both. Just need to generate the public/private keys for the dkim stuff, set the path/owner/permissions for it's use, then generate the key/cert for sendmail, stick those for it's path/owner/permissions separate. -bruce bje(a)ripco.com |