Re: Misunderstanding and/or possible bug regarding SNI
Le lundi 26 juillet 2021 à 04:43 -0700, Chris Brannon a écrit : > papush writes: > > > Hello, > > I'm having issues getting SNI to work, or maybe I'm > > misunderstanding > > its purpose. > > You don't need SNI just to host mail for multiple domains, though > maybe > there are other reasons you might want it. I host multiple domains > on > my mail server hurricane.the-brannons.com. Two of them are > the-brannons.com and blvuug.org. > Both of those domains just have an MX record pointing to > hurricane.the-brannons.com, so a certificate for > hurricane.the-brannons.com is good enough to authenticate the MX for > all > of those domains. > I understand, but I would rather keep my domains separate for privacy concerns, so one sending an email to one domain would not find out about the other domain. I realize this might not be the most reasonable use-case
Re: Misunderstanding and/or possible bug regarding SNI
Le 26/07/2021 à 13:24, papush a écrit : Hello, I'm having issues getting SNI to work, or maybe I'm misunderstanding its purpose. I have three domains, all pointing to the same server, and would like opensmtpd to serve the right certificate depending on which one was used for the connection. The manpage mentions using "*" as a pki name for SNI, so my first attempt was something like: pki "*" cert "/etc/certs/domain1/fullchain.pem" pki "*" key "/etc/certs/domain1/privkey.pem" pki "*" cert "/etc/certs/domain2/fullchain.pem" pki "*" key "/etc/certs/domain2/privkey.pem" ... listen on 0.0.0.0 tls pki "*" I wasn’t aware of that, and I don’t use it. But I don’t think you should have a `pki` on the `listen on` directive in this case. However that lead to the last pki cert/key defined always being used. Looking at the archive of this mailing list it seems what I should be doing is: pki domain1 cert "/etc/certs/domain1/fullchain.pem" pki domain1 key "/etc/certs/domain1/privkey.pem" pki domain2 cert "/etc/certs/domain2/fullchain.pem" pki domain2 key "/etc/certs/domain2/privkey.pem" ... listen on 0.0.0.0 tls leaving out the pki option of the listen directive, but that didn't work, the debug output of smtpd saying that it is 'looking up pki "okanieba"' (my hostname) followed by a disconnection "reason=ca- failure". That does work for me, although note that I specify a `hostname myhostname.domain.name` in the listen directive which might make a difference. Wanting my server to get back to a "working" state where it simply serves the wrong certificate but proceeds happily if the client doesn't mind, i changed the listen directive to 'listen on 0.0.0.0 tls pki domain1', and to my surprise that also made SNI work? The debug output always says it looks up domain1's pki, but when supplying domain2 as server name on connection it serves domain2's certificate. Is this expected behavior? Also, what is the purpose of "*" then? Which smtpd version do you have? In 6.9, the man page changed and `*` is not mentioned anymore, and instead the `pki` option of `listen` says this: > This option can be used multiple times to provide alternate certificates for SNI. So not sure what was the expected behaviour before, but it does work for me without `*` nor `pki` option on `listen` directives.
Re: Misunderstanding and/or possible bug regarding SNI
Le 26/07/2021 à 13:43, Chris Brannon a écrit : papush writes: Hello, I'm having issues getting SNI to work, or maybe I'm misunderstanding its purpose. You don't need SNI just to host mail for multiple domains, though maybe there are other reasons you might want it. I host multiple domains on my mail server hurricane.the-brannons.com. Two of them are the-brannons.com and blvuug.org. Both of those domains just have an MX record pointing to hurricane.the-brannons.com, so a certificate for hurricane.the-brannons.com is good enough to authenticate the MX for all of those domains. That does not answer the question though. I don’t want to tell my users that they need to setup hurricane.the-brannons.com as smtp for their blvuug.org account for instance. So SNI is nice in this case. ;)
Re: Misunderstanding and/or possible bug regarding SNI
papush writes: > Hello, > I'm having issues getting SNI to work, or maybe I'm misunderstanding > its purpose. You don't need SNI just to host mail for multiple domains, though maybe there are other reasons you might want it. I host multiple domains on my mail server hurricane.the-brannons.com. Two of them are the-brannons.com and blvuug.org. Both of those domains just have an MX record pointing to hurricane.the-brannons.com, so a certificate for hurricane.the-brannons.com is good enough to authenticate the MX for all of those domains. -- Chris Brannon Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/). Personal website: (https://the-brannons.com/) Chat: IRC: teiresias on libera.chat and OFTC, XMPP: ch...@chat.number89.net
Misunderstanding and/or possible bug regarding SNI
Hello, I'm having issues getting SNI to work, or maybe I'm misunderstanding its purpose. I have three domains, all pointing to the same server, and would like opensmtpd to serve the right certificate depending on which one was used for the connection. The manpage mentions using "*" as a pki name for SNI, so my first attempt was something like: pki "*" cert "/etc/certs/domain1/fullchain.pem" pki "*" key "/etc/certs/domain1/privkey.pem" pki "*" cert "/etc/certs/domain2/fullchain.pem" pki "*" key "/etc/certs/domain2/privkey.pem" ... listen on 0.0.0.0 tls pki "*" However that lead to the last pki cert/key defined always being used. Looking at the archive of this mailing list it seems what I should be doing is: pki domain1 cert "/etc/certs/domain1/fullchain.pem" pki domain1 key "/etc/certs/domain1/privkey.pem" pki domain2 cert "/etc/certs/domain2/fullchain.pem" pki domain2 key "/etc/certs/domain2/privkey.pem" ... listen on 0.0.0.0 tls leaving out the pki option of the listen directive, but that didn't work, the debug output of smtpd saying that it is 'looking up pki "okanieba"' (my hostname) followed by a disconnection "reason=ca- failure". Wanting my server to get back to a "working" state where it simply serves the wrong certificate but proceeds happily if the client doesn't mind, i changed the listen directive to 'listen on 0.0.0.0 tls pki domain1', and to my surprise that also made SNI work? The debug output always says it looks up domain1's pki, but when supplying domain2 as server name on connection it serves domain2's certificate. Is this expected behavior? Also, what is the purpose of "*" then? Regards, papush
