-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uhttpd: DER Certificate chain not being walked, FireFox and SSL Labs fail. #2797
Comments
Cannot confirm that, uhttpd with ustream-polarssl backend delivers the entire cert chain. Did you concat your domain cert and the intermediate X3 cert into a single pem file? |
Yes, I also tried the fullroot cert (all supplied as pem) and many other things like converting to .key and .crt format. Some attempts, the certificate was not accepted so they were definitely incorrect. But those attempts that were acceptable and included the full chain (to the best of my knowledge as they worked with other apps) worked fine with Chromium (as in it did not complain and said that the site was secure), but both Firefox and SSL Labs said that the full chain was unavailable and therefore the site was not fully secure. I am going to try another free SSL certificate provider, as soon as I have a little time, jut be sure that it is not a problem with those provided by Let's Encrypt (creating one with StartSSL). The certs are 4096 bit, and I have also tried tried with a 4096 DH cert concat-ed. I tried convertion using discrete openssl commands and this online converter. Maybe the problem is mine but it has not been so difficult to apply them, at least it has not been with any other app. :/ Ref: https://wiki.openwrt.org/doc/howto/certificates.overview Edit: I should mention that I'm using trunk (LEDE), if you hadn't guessed. :)
|
I have now tried another signed certificate. The results. https://www.ssllabs.com/ssltest/analyze.html?d=baldr.suka.se&latest I have left uhttpd facing the internet for a little while, so you can connect, if that helps. This is output as seen on Chromium That is domain and intermediate.
|
It would be more interesting to know how you configured it. Also what ustream backend is in use? |
Isn't that what you mean? After concat of domain and intermediate pem files, I converted to DER using openssl. I also converted the private key with openssl I then uploaded these through the luci interface and restarted the service. Config
I find it strange that Chromium sees it and is ok with it but Firefox and SSL Labs are not receiving the whole thing. If I download the cert via SSL Labs, I only get the domain part. |
I mean just "cat mydomain.pem intermediate.pem > public.pem" then use The end result should be a plaintext file with two |
I only converted to DER because that is what it states in the luci GUI and the documents. https://wiki.openwrt.org/doc/howto/certificates.overview I have now uploaded the PEM versions. Chromium sees it the same as the screenshot above, but now SSL Labs sees the whole thing too (scoring A- compared to Nginx A+, though I have done more work on the Nginx setup whereas uhttpd is out of the box) and so does Firefox. https://www.ssllabs.com/ssltest/analyze.html?d=baldr.suka.se&latest |
Closing as uhttpd is in OpenWrt's main repo |
I can confirm that uhttpd also accepts PEM files. That's the way for supplying a certificate chain. (Tested on OpenWrt 19.07.3) |
I wanted to use uhttp as a web facing service, it was already installed with SSL enabled for luci, I soon found problems with certificates (signed by Let's Encrypt) in that it was not honouring a full walk of the certificate chain, whatever I tried and I could only manage a B grade result with SSL Labs. Firefox also complained that the site was unsafe as the certificate chain was not being walked. I have use the same certificate on Apache, Nginx, znc and some other services, and they have worked just fine on those.
I see than several years people were having the same problem with uhttpd, an example on the forums: https://forum.openwrt.org/viewtopic.php?id=29120 there was also ticket raised an the problem closed as fixed: https://dev.openwrt.org/ticket/12457
The text was updated successfully, but these errors were encountered: