ok san is only useable if the cert is setup that way
i bought a proper *.scom.ca wildcard ssl cert for my domain
i then buy mail.xxx.com certs for the other domains
sni works well when configured this way.
granted san might or might not work (i never tries that) however san was
designed more for apache web servers vs email etc
san does allow adding domains but i more complicated to control what the
cert is doing (or not)
sound like what i did will work better for you situation
example sni.conf file (import this at the end of your main dovecot.conf file
using :
#Addition ssl config
!include sni.conf
please note that below i wront a python script to pull the cert from a
db table
getssl.cert
all it does it return the text for the ssl cert (key first then
certificate then both Intermediate certs)
you can point this to an ssl key file (the old way) formatted the same
either will work
note you need both the default cert setup AND the local name as well
a *. signifies a wildcard ssl cert
like *.scom.ca
note you need to do something similiar in postfix as well for this to
work across smtp + dovecot
# cat sni.conf
#sni.conf
ssl = yes
verbose_ssl = yes
ssl_dh =</usr/local/etc/dovecot/dh-4096.pem
ssl_prefer_server_ciphers = yes
#ssl_min_protocol = TLSv1.2
#Default *.scom.ca
ssl_key =</usr/local/etc/dovecot/scom.pem
ssl_cert =</usr/local/etc/dovecot/scom.pem
ssl_ca =</usr/local/etc/dovecot/scom.pem
local_name .scom.ca {
ssl_key = /programs/common/getssl.cert -c *.scom.ca -q yes
ssl_cert = /programs/common/getssl.cert -c *.scom.ca -q yes
ssl_ca = /programs/common/getssl.cert -c *.scom.ca -q yes
}
local_name mail.clancyca.com {
ssl_key = /programs/common/getssl.cert -c mail.clancyca.com -q yes
ssl_cert = /programs/common/getssl.cert -c mail.clancyca.com -q yes
ssl_ca = /programs/common/getssl.cert -c mail.clancyca.com -q yes
}
local_name secure.clancyca.com {
ssl_key = /programs/common/getssl.cert -c secure.clancyca.com -q yes
ssl_cert = /programs/common/getssl.cert -c secure.clancyca.com -q yes
ssl_ca = /programs/common/getssl.cert -c secure.clancyca.com -q yes
}
local_name mail.paulkudla.net {
ssl_key = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
ssl_cert = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
ssl_ca = /programs/common/getssl.cert -c mail.paulkudla.net -q yes
}
local_name mail.ekst.ca {
ssl_key = /programs/common/getssl.cert -c mail.ekst.ca -q yes
ssl_cert = /programs/common/getssl.cert -c mail.ekst.ca -q yes
ssl_ca = /programs/common/getssl.cert -c mail.ekst.ca -q yes
}
local_name mail.hamletdevelopments.ca {
ssl_key = /programs/common/getssl.cert -c mail.hamletdevelopments.ca
-q yes
ssl_cert = /programs/common/getssl.cert -c mail.hamletdevelopments.ca
-q yes
ssl_ca = /programs/common/getssl.cert -c mail.hamletdevelopments.ca
-q yes
}
Happy Wednesday !!!
Thanks - paul
Paul Kudla
Scom.ca Internet Services <http://www.scom.ca>
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3
Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266
On 5/18/2022 3:31 PM, Frank Gingras wrote:
> See if you can add a SAN to that wildcard certificate first.
>
> On Wed, 18 May 2022 at 15:21, frank picabia <fpicabia@xxxxxxxxx
> <mailto:fpicabia@xxxxxxxxx>> wrote:
>
>
> We have a server with over 300 vhosts on it. Marketing/CMS madness
> I guess.
> All on the same domain name. Many VirtualHosts are defined with *:443
> and then ServerName to rely on SNI.
> We have a wildcard cert for the domain and all the hosts use that.
>
> Now there is a different domain to add for SSL. For some reason
> the first domain name's certificate is being found. I've put the
> IP for our new comer domain so we have <VirtualHost *MailScanner
> warning: numerical links are often malicious:* 1.1.1.1:443
> <http://1.1.1.1:443> >
> but it is still finding the other cert. This IP is uniquely assigned
> with the different domain, as you'd expect with DNS. So it can't
> be a overlap of the IP used elsewhere.
>
> Researching this problem ("wrong cert loaded for vhost"),
> I read that in the initial SSL connection, it
> is talking to the IP, and whatever values we have for ServerName
> have no bearing until the page is being accessed. If that's the case
> then it might have matched another vhost with *:443 first
> I tried putting my new domain at the top of ssl.conf but it made no
> difference.
>
> I'm thinking I need to edit each *:443 case and change it to the
> appropriate IP.
> That will be a lot of work, so I'm looking for affirmation that is
> likely to make the difference.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|