Different SSL cert slow down site?

ssl

#1

Hi,

I am using a dedicated edge SSL certificate with cloudflare on Full strict, at the same time I have another SSL certificate from COMODO in my NGINX configuration on my origin server.

Will this slow down the load time of the site as it needs to do 2 SSL certificate checks?


#2

A little, but not so much I’d worry about it. But you can install a Cloudflare Origin certificate that’s already internally validated and that will save you that time:


#3

Thanks, but I looked at the instructions for nginx, and the generator only gives me the pvt key and pem file, it does not give the CSR. I tried other browsers too and the popup does not give the CSR.

How do I generate the corresponding CSR for the keys?


#4

It actually looks like even though I got the orange cloud enabled in DNS (going through cloudflare), the traffic isn’t going through cloudflare hence that might be why the certificate dose not work. my subdomain is www-staging.xxxxxxx.com

Are subdomains with a dash supported?


#5

To generate a CSR, you’d have to do it from the command line of your Linux server:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

I’m not aware of any problems using a dash in your subdomain. But you’re saying that SSL works through your domain, but not your subdomain? If your (sub)domain is set to :orange:, it would seem that it has to go through Cloudflare. What makes you think it isn’t? And your main domain is?


#6

Yes, my main domain and subdomain both has the orange cloud and the main one goes through cloudflare, so I can see it using the edge certificate. But the subdomain is still using the original COMODO essential SSL cert.

The subdomain just doesn’t pick up the same cloudflare cert as the main site.


#7

And the subdomain doesn’t return any Cloudflare HTTP headers? You can see this using the Dev Tools window in your browser.

It’s possible there’s some DNS issue where your Subdomain is still showing up in DNS with its origin IP address. If you post your (sub)domain, I can take a look.


#8

Thanks, here is the link to my subdomain:

and the main domain, just replace www-staging with www


#9

Staging and Main are using a shared Cloudflare SSL certificate (sni214104.cloudflaressl.com). The .svg images you’re using on both sites are showing a HIT by Cloudflare’s cache.

You can check global DNS for both sites at https://www.whatsmydns.net/

As an aside, I see you’re using Cloudfront. Have you looked into using a CNAME so image URLs use a subdomain under your domain instead of Cloudfront?
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html

Admittedly, it’s probably not easy to get this configuration to work with Full (Strict) SSL, but it may be possible:
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-and-https-procedures.html


#10

Thanks for the advice on cloudflare.

Strangely, as you can see in my attached photos, the main site is hitting the cloudflare ssl cert and the sub-domain is hitting my original comodo cert. I would have thought they would both fit the cloudflare shared ssl one?


#11

It looks like our browsers disagree (I double-checked). For some reason, it appears your Mac just isn’t getting the updated DNS address for your staging site.

  1. Did you manually add a DNS entry to your Mac’s /etc/hosts file for your staging site?
  2. How about changing your Mac’s DNS servers to 8.8.8.8 and 8.8.4.4 in System Network Preferences?


#12

Yes, I have the ip mapped to the url in my local /etc/hosts file but I have done this for both production and staging so this probably wouldn’t be the cause as I would expect the same behaviour for both.

I did comment out the host file entry and also changed the DNS as suggested and still the same, so a bit strange…