Re:SSL certificate chain resolver
by nadams on Sunday January 18, 2015 @11:25AM
(#8907858)
That is what I suspected - in order to get an "A+" you have to recompile the web server (the article is for nginx but the same idea applies to Apache). I'm not saying this is a difficult process - but not something I want to do on a production system.
While, distro maintainers usually do a great job of maintaining software - I think it does highlight a certain need for another way to easily install bleeding edge without adding a whole other repo (which could contain/override versions of other software you may not want). You can always rpm/dpkg an individual package - but now your version will never been updated by the package manager, well by yum update/apt-get upgrade anyways (or even worse overwritten).
Re:SSL certificate chain resolver
by nadams on Sunday January 18, 2015 @07:37PM
(#8909659)
Upon further research it looks like recompiling may no longer be needed. I remember awhile back some feature in a newer version of Apache - however I may be confusing that with my Ubuntu 10.04 (most of my other systems run Debian Wheezy).
In any case - PPAs are a patch for the problem not a solution (and specific to Ubuntu). PPAs require third-party support and if a security issue is found and he (or they) are on vacation - your custom version of Apache is vulnerable. It's not a big issue for something like Wine, but I would just have a warm fuzzy feeling if the security team behind the distro supported it.
I'm even guilty of using random debs however I always check for red flags and go with my gut feeling. I have worked with a group of Linux people who refused to install packages I wanted from the Red-Hat community repos onto the servers (though they would freely install packages they wanted...)
Re:SSL certificate chain resolver
by peterwaller on Sunday January 18, 2015 @06:41AM
(#8907279)
I've lost count of how many times I had to try reordering the certificates I fed to Amazon's load balancer. You get back very cryptic error messages. Which is annoying since it could almost certainly work out the order for you...
Re:SSL certificate chain resolver
by jpetersonmn on Sunday January 18, 2015 @08:39AM
(#8907478)
I just went through this issue with my first site I've used ssl on. I thought everything was all good until I visited the site on my phone and got cert errors. Took me all night to figure out how to get them in the correct order, etc... Thanks for sharing this.
Re:SSL certificate chain resolver
by praseodym on Sunday January 18, 2015 @08:28AM
(#8907459)
One thing to note is that the Qualys SSL Labs test will complain if your server sends the (self-signed) root CA certificate, which will already be in the end-user's trust store. This uses unnecessary bandwidth for every TLS negotiation.
In many cases, the CA (or company you got your certificate from) will include this root cert in the chain. With most web servers it is perfectly fine to simply remove it, but I have seen applications where you cannot (VMware, which wants a complete chain ending with a self-signed cert) and where you'll have to ignore the SSL Labs warning.
Re:SSL certificate chain resolver
by zakjan on Sunday January 18, 2015 @09:02AM
(#8907526)
Yes, you are right, a root cert shouldn't be sent by server. My script doesn't append it to output, because (I hope) no intermediate certificate has AIA extension pointing to the root cert. If you find a counterexample, please file an issue, I will add a check.
Re:SSL certificate chain resolver
by iancarroll on Sunday January 18, 2015 @10:37AM
(#8907740)
A tangent of this is where you will get many irrelevant warnings due to compatibility chains. Comodo uses "Comodo <keytype> Certification Authority" but this has to be sent with your request as not all clients trust it, but they will trust the issuer.
A related post worth reading is "Getting an A+ on Qualy's SSL Labs Tester" - https://sethvargo.com/getting-an-a-plus-on-qualys-ssl-labs-t...
Previous HN discussion: https://news.ycombinator.com/item?id=8749931
While, distro maintainers usually do a great job of maintaining software - I think it does highlight a certain need for another way to easily install bleeding edge without adding a whole other repo (which could contain/override versions of other software you may not want). You can always rpm/dpkg an individual package - but now your version will never been updated by the package manager, well by yum update/apt-get upgrade anyways (or even worse overwritten).
Do PPAs not fit your use case?
In any case - PPAs are a patch for the problem not a solution (and specific to Ubuntu). PPAs require third-party support and if a security issue is found and he (or they) are on vacation - your custom version of Apache is vulnerable. It's not a big issue for something like Wine, but I would just have a warm fuzzy feeling if the security team behind the distro supported it.
I'm even guilty of using random debs however I always check for red flags and go with my gut feeling. I have worked with a group of Linux people who refused to install packages I wanted from the Red-Hat community repos onto the servers (though they would freely install packages they wanted...)
This script looks very useful, thanks :)
https://cheapsslsecurity.com/comodo/positivessl.html
If that's a barrier, I don't know what to say. Registering the domain name probably costs twice that.
In many cases, the CA (or company you got your certificate from) will include this root cert in the chain. With most web servers it is perfectly fine to simply remove it, but I have seen applications where you cannot (VMware, which wants a complete chain ending with a self-signed cert) and where you'll have to ignore the SSL Labs warning.