To be fair the live.sagepay.com domain, which processs all payments, is under a different certificate, so this would have only affected their portal.
Doh! Sage Pay forgets to renew SSL certificate
Customers logging into "secure and efficient payment service" Sage Pay this morning were served up an error message saying that the site could not be trusted, and didn't have a valid security certificate. SSL certificate error message, credit: screengrab Looks like someone forgot to renew the site's SSL certificate – which …
-
Thursday 26th April 2012 17:15 GMT Anonymous Coward
ah, load balancers
Especially ones not managed by the same folks that manage the webservers themselves.
This raises a question to which I'd appreciate frank, brutal or even silly answers: If you have load balancers and provide SSL connections, do you use the same CA-issued certificate on both your load balancers and your backend web servers? Or do you only install the CA-issued certificate on your load balancers and use internal-CA-signed certificates internally? The downside being having to manage additional certificates, and the upside being that your internal certificates can be issued for 10 years and as long as they don't all expire on the same day, while you may run degraded for 30 minutes if one of your servers is taken out of the pool, you won't go down hard.
-
Friday 27th April 2012 07:26 GMT parama
Re: ah, load balancers
Typically you'd just install the certificate on the reverse proxies (acting as both load balancers and failover) and then skip SSL encryption between the reverse proxies and application servers since you are already inside a closed network, usually just transfering TCP packages between the DMZ and application server network through the firewall. This saves the SSL encryption overhead and enables you to geek away with content caching options on the RP's as well.
-
-
-