On Sun, Feb 16, 2014 at 10:44:39AM +0100, Remco wrote: > Frank Brodbeck wrote: > > > Hi, > > > > On Fri, Feb 14, 2014 at 07:24:32PM -0500, Ted Unangst wrote: > >> I would try using a full path. > >> > >> pki example ca "/etc/ssl/myca.pem" > > > > I already tried it with full path. But I got it working now by > > specifying certificate and key, too: > > > > pki example certificate "/etc/ssl/relay.crt" > > pki example key "/etc/ssl/private/relay.key" > > pki example ca "/etc/ssl/ca.crt" > > > > and later on: > > > > accept from any for domain example.tld relay via tls://relay.example.tld > > pki example verify > > > > But I am still wondering if I am doing it right. Because normally it > > should be enough to have the signing certificate and it shouldn't be > > neccessary to provide the peer's cert and key or am I wrong here? > > > > From smtpd.conf(5) on OpenBSD 5.4: > (You seem to run CURRENT, which I didn't check, so things might be different > in your case) > > [...] >
yes a few things have changed > The way I understand it, this is useful when smtpd is used as a "submission" > relay. It uses the key/cert pair to set up an encrypted connection to a > remote server. At the remote end the certificate can potentially be used as a > means of client authentication. In this case I think you shouldn't specify > the peer's certificate but your host's certificate/key pair instead. > > You seem to want it the other way around, you want clients that set up an > encrypted connection to your server to be verified (authenticated) by means > of their certificate. I'm not aware if this is possible with smtpd, but I've > never looked into it either. > both ways are supported, smtpd(8) works both as a server when accepting connections and as a client when relaying messages. using the "verify" keyword on a listen line will require that a client provide a certificate that we can verify before a session can be started whereas using a verify on a relay line will require that smtpd(8)'s own client can verify a peer certificate before relaying a message. -- Gilles Chehade https://www.poolp.org @poolpOrg
