Site Certificate error

willsnow

One of Us
Ski Pass
Jul 19, 2017
368
645
263
Been getting issues with accessing the site via both Chrome and Firefox. Looks like the site certificate has expired.

Screenshot_1.png
 
Last edited:

crackson

Part of the Furniture
Ski Pass
Oct 20, 2006
12,594
12,724
813
Just move the date on your device back one day and it will stop, for one day.

I'm sure they will sort it soon so just move the date back one day and relax.
 

Astro66

Still looking for a park in Thredbo
Ski Pass
Jul 27, 2009
19,159
17,696
813
Eastern Subs Syd
Just move the date on your device back one day and it will stop, for one day.

I'm sure they will sort it soon so just move the date back one day and relax.
I was able to get through fine. But it's kind of sad talking to yourself for hours. LOL
 
  • Like
Reactions: crackson
Remove ads with a
Ski Pass

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
Ok - now the dust has settled.. for the nerds, here's what happened

So.. A month ago I get the certificate renewal notice from sslstore.com. I promptly renew the certificate for two years. This is the first time I've done a renewal instead of an initial purchase.

I'm using DNS CNAME validation. No change required as it's a renewal and the CNAME values don't change.

It sits in 'pending' on SSL store - I change the TTL from 24 hrs to 1 hr just for giggles.

A couple days later it's still in pending, I contact support - they tell me it's awaiting the validation from Comodo - so I delete and resave the CNAME entry and give it 5 min TTL as recommended (300).

A week later it's still pending, I again I ask - same response (awaiting validation from Comodo)

Since then basically I forget about it - in theory the certificate just renews at Comodo and we carry on seamlessly.

- then today I'm out of the office and Carveman messages me... Aaaark, so an hour before I can get back to desk.

Cert is still 'pending' and no live support at SSL store.

I go to comodo official site and get live support.

The CNAME validation had (of course) been accepted weeks ago. But... it turns out that the CAA record which I added to our DNS about 5 months ago (using the SSL-Store's CAA generator, oh the irony!) was preventing anyone issuing a certificate - with the exception of Comodo issuing it *directly*.

The TTL on the CAA record is 24 hours, so I have no choice but to buy another certificate direct from Comodo (at four times the price!) - the alternative is to let the site go broken for anywhere up to 48 hours.

So, I buy and it takes about 40 min to implement all new certs.

But there is more - the chat support at comodo, whilst quickly working out that the CAA record was the problem, then tried to tell me that I could do nothing except change the TTL and hope it propagates quickly. I had to argue with them that buying directly would solve the problem - "no it wouldn't" - but I ignored that advise and purchased anyway and of course a certificate was issued automatically within 2 minutes of me updating the CNAME ssh hashes. sheesh, I had to argue to buy their product??

---

Takeaway's.
- Most technical support don't know their stuff that deeply, that's why they are the ones on the other side of online chat.
- CAA is a security mechanism that really works - too well! I set it up because I like knowing how to configure rock solid TLS and get A+ security rating (it's good for my consulting).
- I now truly know what the nuances of config of a CAA record do!
- One should set a calendar event 48 hours prior to TLS certs expiring to double check all is well - this was my fundamental mistake, I forgot to follow through after my last support interaction with SSL store.
 

willsnow

One of Us
Ski Pass
Jul 19, 2017
368
645
263
Sometimes learning the hard way is the best way. LOLLOL

Glad it all worked out.

Ok - now the dust has settled.. for the nerds, here's what happened

So.. A month ago I get the certificate renewal notice from sslstore.com. I promptly renew the certificate for two years. This is the first time I've done a renewal instead of an initial purchase.

I'm using DNS CNAME validation. No change required as it's a renewal and the CNAME values don't change.

It sits in 'pending' on SSL store - I change the TTL from 24 hrs to 1 hr just for giggles.

A couple days later it's still in pending, I contact support - they tell me it's awaiting the validation from Comodo - so I delete and resave the CNAME entry and give it 5 min TTL as recommended (300).

A week later it's still pending, I again I ask - same response (awaiting validation from Comodo)

Since then basically I forget about it - in theory the certificate just renews at Comodo and we carry on seamlessly.

- then today I'm out of the office and Carveman messages me... Aaaark, so an hour before I can get back to desk.

Cert is still 'pending' and no live support at SSL store.

I go to comodo official site and get live support.

The CNAME validation had (of course) been accepted weeks ago. But... it turns out that the CAA record which I added to our DNS about 5 months ago (using the SSL-Store's CAA generator, oh the irony!) was preventing anyone issuing a certificate - with the exception of Comodo issuing it *directly*.

The TTL on the CAA record is 24 hours, so I have no choice but to buy another certificate direct from Comodo (at four times the price!) - the alternative is to let the site go broken for anywhere up to 48 hours.

So, I buy and it takes about 40 min to implement all new certs.

But there is more - the chat support at comodo, whilst quickly working out that the CAA record was the problem, then tried to tell me that I could do nothing except change the TTL and hope it propagates quickly. I had to argue with them that buying directly would solve the problem - "no it wouldn't" - but I ignored that advise and purchased anyway and of course a certificate was issued automatically within 2 minutes of me updating the CNAME ssh hashes. sheesh, I had to argue to buy their product??

---

Takeaway's.
- Most technical support don't know their stuff that deeply, that's why they are the ones on the other side of online chat.
- CAA is a security mechanism that really works - too well! I set it up because I like knowing how to configure rock solid TLS and get A+ security rating (it's good for my consulting).
- I now truly know what the nuances of config of a CAA record do!
- One should set a calendar event 48 hours prior to TLS certs expiring to double check all is well - this was my fundamental mistake, I forgot to follow through after my last support interaction with SSL store.
 

K@os

A Local
Aug 12, 2005
8,233
695
563
41
South Australia
Ok - now the dust has settled.. for the nerds, here's what happened

So.. A month ago I get the certificate renewal notice from sslstore.com. I promptly renew the certificate for two years. This is the first time I've done a renewal instead of an initial purchase.

I'm using DNS CNAME validation. No change required as it's a renewal and the CNAME values don't change.

It sits in 'pending' on SSL store - I change the TTL from 24 hrs to 1 hr just for giggles.

A couple days later it's still in pending, I contact support - they tell me it's awaiting the validation from Comodo - so I delete and resave the CNAME entry and give it 5 min TTL as recommended (300).

A week later it's still pending, I again I ask - same response (awaiting validation from Comodo)

Since then basically I forget about it - in theory the certificate just renews at Comodo and we carry on seamlessly.

- then today I'm out of the office and Carveman messages me... Aaaark, so an hour before I can get back to desk.

Cert is still 'pending' and no live support at SSL store.

I go to comodo official site and get live support.

The CNAME validation had (of course) been accepted weeks ago. But... it turns out that the CAA record which I added to our DNS about 5 months ago (using the SSL-Store's CAA generator, oh the irony!) was preventing anyone issuing a certificate - with the exception of Comodo issuing it *directly*.

The TTL on the CAA record is 24 hours, so I have no choice but to buy another certificate direct from Comodo (at four times the price!) - the alternative is to let the site go broken for anywhere up to 48 hours.

So, I buy and it takes about 40 min to implement all new certs.

But there is more - the chat support at comodo, whilst quickly working out that the CAA record was the problem, then tried to tell me that I could do nothing except change the TTL and hope it propagates quickly. I had to argue with them that buying directly would solve the problem - "no it wouldn't" - but I ignored that advise and purchased anyway and of course a certificate was issued automatically within 2 minutes of me updating the CNAME ssh hashes. sheesh, I had to argue to buy their product??

---

Takeaway's.
- Most technical support don't know their stuff that deeply, that's why they are the ones on the other side of online chat.
- CAA is a security mechanism that really works - too well! I set it up because I like knowing how to configure rock solid TLS and get A+ security rating (it's good for my consulting).
- I now truly know what the nuances of config of a CAA record do!
- One should set a calendar event 48 hours prior to TLS certs expiring to double check all is well - this was my fundamental mistake, I forgot to follow through after my last support interaction with SSL store.

You only have an A rating, not A+, configure HSTS and you'll get A+ with your current config - that will also force everyone's browser to always use HTTPS, without the need to hit the redirect, which offers an extra layer of security.

Looks like you are using AWS these days, so why not use AWS Certificate Manager to auto-renew? That's the beauty of AWS right - automation! If you cant do that for some reason, try ACME :)
 

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
The next element is content security policy in the request headers, but I can't do that until I have set up proxy serving for all the linked images on this forum - which I've made steps toward but it's a reasonable project and not critical.
 

K@os

A Local
Aug 12, 2005
8,233
695
563
41
South Australia
You mean the HSTS that's been in place for 10 months?

Who you testing on that only gets an A ??

secure-test.jpg
Here's what I get when I do the test @Richard
29122665437_01a2792473_b.jpg

30191922508_8c1e3b995e.jpg


Your other option for CSP is to exclude certain file types from your policy, and only concern yourself with the more dangerous stuff like scripts, though that might be tough. Cloudfront may help with this as well, which would also give you the benefits of CDN and DDOS protection, with that comes Route53 DNS, which also gives you auto failover.
 

K@os

A Local
Aug 12, 2005
8,233
695
563
41
South Australia
Interestingly, when I use the query tool embedded in chrome (chrome://net-internals/#hsts) it confirms you have HSTS.

When I run the SSLLabs test from Edge I get an A, with no HSTS (from work and home). When I run it from Chrome I get A+

When I run the sites I manage from edge or chrome the result is consistent. I'm thinking load balancer and one of your servers is not configured, or some weird discrepancy in your config that Edge doesn't like - though I would have thought that SSLLabs wouldn't rely on my client to do the tests, but maybe it does?
 

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
Here's what I get when I do the test @Richard


Your other option for CSP is to exclude certain file types from your policy, and only concern yourself with the more dangerous stuff like scripts, though that might be tough. Cloudfront may help with this as well, which would also give you the benefits of CDN and DDOS protection, with that comes Route53 DNS, which also gives you auto failover.

Looks like you are testing a 301 redirect. But that's interesting, I'll see if I can add the HTST header for that in my nginx.

ssl test 2.jpg

HSTS is on, it's in every header referrer, including subdomains.

I'm using Route53.

I find Cloudfront is too slow for static assets and it needs too much config to play nice with my CMS for the page files.

In fact I find every CDN I have tried (about five) is a tad too slow v's just aliasing my cdn domain to hit nginx. This is especially true with the snow cam images (cams.ski.com.au) 98% of traffic is AU and the assets are best served straight from the AU data center instance. The cams have a max cache of five minutes any CDN significantly slows down the traffic as it is constantly fetching and caching - too many hops.
 
  • Like
Reactions: K@os

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
Interestingly, when I use the query tool embedded in chrome (chrome://net-internals/#hsts) it confirms you have HSTS.

When I run the SSLLabs test from Edge I get an A, with no HSTS (from work and home). When I run it from Chrome I get A+

When I run the sites I manage from edge or chrome the result is consistent. I'm thinking load balancer and one of your servers is not configured, or some weird discrepancy in your config that Edge doesn't like - though I would have thought that SSLLabs wouldn't rely on my client to do the tests, but maybe it does?

No load balancer - it's a single instance (t2.large). Aurora RDS cluster (2 x db.t2.medium)
 
  • Like
Reactions: K@os

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
Your other option for CSP is to exclude certain file types from your policy, and only concern yourself with the more dangerous stuff like scripts, though that might be tough

I like this idea, will let that stew away in the back of my mind. I may have chance to research exactly best how to configure it with another project I'm on atm.

I haven't pushed through the effort of knowing the nuances of CSP yet.
 

K@os

A Local
Aug 12, 2005
8,233
695
563
41
South Australia
Looks like you are testing a 301 redirect. But that's interesting, I'll see if I can add the HTST header for that in my nginx.

ssl test 2.jpg

HSTS is on, it's in every header referrer, including subdomains.

I'm using Route53.

I find Cloudfront is too slow for static assets and it needs too much config to play nice with my CMS for the page files.

In fact I find every CDN I have tried (about five) is a tad too slow v's just aliasing my cdn domain to hit nginx. This is especially true with the snow cam images (cams.ski.com.au) 98% of traffic is AU and the assets are best served straight from the AU data center instance. The cams have a max cache of five minutes any CDN significantly slows down the traffic as it is constantly fetching and caching - too many hops.
That's interesting, we are about to replace akami with CloudFront (cost difference is astronomical) and will also look at adding it to our other products (true SaaS applications), mainly for DDOS, but if its going to add significant response times we might need to reconsider something like an F5 device in the DC.

Have you looked at CloudFlare? Most of our users are AU/NZ & Manila
 

Seafm

Too far from the snow
Ski Pass
Jun 5, 2014
6,493
8,823
563
60
Cairns, Queensland
The next element is content security policy in the request headers, but I can't do that until I have set up proxy serving for all the linked images on this forum - which I've made steps toward but it's a reasonable project and not critical.
Does this mean that images linked back to Photobucket will be visible again?
 

Richard

Maintenance Dept
Administrator
Mar 14, 1995
15,559
22,375
813
Clarence Town
That's interesting, we are about to replace akami with CloudFront (cost difference is astronomical) and will also look at adding it to our other products (true SaaS applications), mainly for DDOS, but if its going to add significant response times we might need to reconsider something like an F5 device in the DC.

Have you looked at CloudFlare? Most of our users are AU/NZ & Manila

Cloudflare is pretty impressive, it has built in 'art direction' on images for different device responsiveness and a whole bunch of features that make it attractive at a good price. I have very seriously considered it. But the deal-breaker for me is that I know I have fine-tuned the death out of my cam image serving and I can't be bothered re-structuring again.

Cloudfront is more than fine if you have a truly global audience and for 30day+ cached static assets it's as good as any CDN. A consideration is that you have to take the highest tier service to get AU datacentres in the distribution (this would still be significantly lower cost than Akami). Plus if you are building on the AWS stack anyway then it's kinda a no-brainer.
 
  • Like
Reactions: K@os
Remove ads with a
Ski Pass

Log in

or Log in using
Remove ads with a
Ski Pass