Hey there, I’m struggling to find the correct answer and unsure if there
even is one.
We have a domain say, example.co and we’ve purchased a wildcard SSL
certificate for it. We want to be able to provide what amounts
to…with
minimal configuration.
This doesn’t appear to work as I would expect it to. Would we need to
set up
a different server for each subdomain explicity. or could we get away
with
one config for example.co and another for *.example.co? I’ve seen
examples
of using the same ssl key for different virtual servers with different
hostnames but not pointing to the same one.
This doesn’t appear to work as I would expect it to. Would we need to set
up
a different server for each subdomain explicity. or could we get away
with
one config for example.co and another for *.example.co?
Doesn’t work in what way? (Does nginx or browser complain/what’s the
error?)
Such configuration is perfectly fine, unless you allready have a server
{}
block for each subdomain then you need to repeat the ssl config for each
one.
The other caveat I can think of would be if the wildcard *.example.co
certificate doesn’t contain Subject Alternate Name for ‘example.co’
(exact
domain without prefix). It depends on CA who issued the certificate -
usually they include the bare domain too but I have seen also different
cases.
This is actually picking up the SSL cert for the default site on the
server.
So the server_name is picking up example.co but *.example.co seems to be
ignored.
Interesting, the wildcard SSL Key is the most basic RapidSSL Wildcard
Certificate, so perhaps going down the Subject Alternate Name route
might
be worthwhile or worth talking to RapidSSL Support about because we also
need *.staging.example.co to work for our staging environment too which
might kill two birds with one stone.
However, this is definitely a different error message so it doesn’t
appear
to be falling back on the default SSL certificate for the server, which
is a
step forward.
The SSL Checking service did indeed point out the error. I will admit to
my
own stupidity on this one. We’re using Elastic Load Balancing on
*.example.co
ELB had only our other SSL Cert configured and not our new one. Darn it.
We
don’t use ELB for example.co because you can’t CNAME the root domain so
that
hit our server directly and of course with the tweaked config worked
fine.
Now I’ve added our new SSL cert to ELB, both urls work fine. Thanks very
much for all of your assistance working through this, although
ultimately it
wasn’t all Nginx.
This is actually picking up the SSL cert for the default site on the
server.
So the server_name is picking up example.co but *.example.co seems to be
ignored.
So are there 2 certificates?
If so you need a different server block for each - one for the exact
domain
and one for the wildcard (or use the wildcard for both).
Besides server_name .example.co and server_name example.co, *.example.co
are
generally the same (the latter actually being recommended Server names )
The only difference would be if you have multiple server {} definitions
(with same domains) because nginx has an order of precedence in which it
decides which virtual server will be chosen (regular expressions (which
is
also .example.co) will be last).
In general you should check (for example with ‘openssl x509 -in
/path/example.co.crt -noout -text | grep DNS’) and see if your nginx
server{} block configuration actually matches the certificates (and
keys)
you point to.
It makes a bit hard to guess not seing the whole config.
One note when testing with curl - on older systems the root certificates
are
not always updated and if the CA has recently changed its intermediate
certificates (iirc for example GoDaddy) curl might report a problem.
Also be sure that the intermediate certificates are included in the
certificate itself ( Configuring HTTPS servers )
we also need *.staging.example.co to work for our staging environment too
which
might kill two birds with one stone.
Standard wildcard certificate *.example.co covers also this, you don’t
need
additional certificates.
p.s. A good/simple way imo (if the server has public access) to check
for
all kinds of issues/ssl chains etc is to use SSL Server Test (Powered by Qualys SSL Labs) (check the “do not show” if you want
hidden
results).
ELB had only our other SSL Cert configured and not our new one. Darn it.
We
don’t use ELB for example.co because you can’t CNAME the root domain so
that
hit our server directly and of course with the tweaked config worked fine.