Wildcard SSL and Wildcard hostnames

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.

https://example.co
https://blah.example.co
https://somerandomsubdomain.example.co

all pointing at the same server so something like

server {
port 443
server_name example.co *.example.co;

ssl on;
ssl_protocols …;
ssl_ciphers …;
ssl_prefer_server_ciphers on;
ssl_certificate /data/nginx/ssl/example.co.crt;
ssl_certificate_key /data/nginx/ssl/example.co.key;
}

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.

Anyone else have any joy with a similar config?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258792#msg-258792

What did you expect?
What did you get?
What did you think you configured?

B. R.

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.

rr

Sorry to be vague.

http://example.co - works fine and as expected.
http://blah.example.co - returns curl: (60) SSL certificate problem:
Invalid
certificate chain

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.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258797#msg-258797

braindeaf Wrote:

server {
port 443
server_name .example.co;

Would be a catch all.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258796#msg-258796

itpp2012 provided you with the answer, also to be found in the
server_name
http://nginx.org/en/docs/http/ngx_http_core_module.html#server_name
directive documentation.

B. R.

braindeaf Wrote:

http://blah.example.co - returns curl: (60) SSL certificate problem:
Invalid certificate chain

Forget one thing, you also need a wildcard DNS entry.

DNS: so it arrives at your frontdoor
Nginx.conf (server_name .example.co;): so you can deal with it

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258799#msg-258799

Thanks for the tip. I have replaced the config with

server_name example.co *.example.co

with

server_name .example.co

While that is definitely more concise it didn’t solve the problem.

http://example.co - seems fine.
http://test.example.co - curl: (51) SSL peer certificate or SSH remote
key
was not OK

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.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258800#msg-258800

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.

Cheers.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,258792,258804#msg-258804

http://example.co - works fine and as expected.
http://blah.example.co - returns curl: (60) SSL certificate problem:
Invalid certificate chain

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
http://nginx.org/en/docs/http/server_names.html#optimization )

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 (
http://nginx.org/en/docs/http/configuring_https_servers.html#chains )

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
https://www.ssllabs.com/ssltest/ (check the “do not show” if you want
hidden
results).

rr

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.

It’s offtopic but technically you can or life always finds a way -
Cloudflare for example offers a workaround as “CNAME flattening”
https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/
with a usecase exactly for ELB.

rr

hi

if you are using amazon you can try their DNS service Route53.

you can point the root domain to an ELB via ALIAS setting.

regards,
ron

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs