Open adament opened 9 years ago
The certificate is generally for personal use, by default the site doesn't offer a secure connection. Maybe one day I'll update it. Maybe... ;-)
No problem, in that case I will just file a bug report with HTTPS Everywhere to disable the bohoomil.com rule.
Thank you for all your amazing work.
A personal signed certificate still enables encryption between the webpage and viewer. Do we really need the cert to be signed off by a trusted cert authority?
Currently only updates and update checks of infinality-bundle & infinality-bundle-multilib go through the network in plain text and I don't think there is any need why anyone would need to know what packages I update etc. so easily, so SSL certificate would be helpful.
Do we really need the cert to be signed off by a trusted cert authority?
Yes, unless you start supporting DNSSEC + DANE and write DANE support for cURL (it's in their todo and has been for a long time) so pacman can download the packages over HTTPS and be sure that the certificate is valid. DANE might not accept expired certificate either though, but self-signed certificate would be valid.
Even now there are trusted certificate authorities that give certificates for free*:
*Quick ducking, I didn't read about those throughly.
There is also CACert which while isn't trusted by everyone appears to be trusted by Arch by default which should extend to cURL and as the repositories are for Arch I think using it would be acceptable.
core/ca-certificates-cacert 20140824-2 [installed]
CAcert.org root certificates
is also recommended a lot from what I can see. Mostly it's suggested at #znc at freenode.
@Mikaela Thanks for the info. I've just applied for a 3 year certificate at wosign and once I get it, I'll install it on the site.
OK guys, it's running fine for me and so it should for you. Please, check it on your side and report back.
@Mikaela Thanks again. It's been a great deal of help.
It works on Chromium, but not pacman.
error: failed retrieving file 'infinality-bundle.db' from bohoomil.com : SSL certificate problem: unable to get local issuer certificate
error: failed to update infinality-bundle (download library error)
error: failed retrieving file 'infinality-bundle-multilib.db' from bohoomil.com : SSL certificate problem: unable to get local issuer certificate
error: failed to update infinality-bundle-multilib (download library error)
What can I do about it?
I don't know
% curl https://bohoomil.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
I think that means that WoSign is either trusted by the browser or cross-signed so that browser trusts it, but it's not part of ca-certificates and cURL doesn't like it.
The trust chain is: bohoomil.com > WoSign CA Free SSL Certificate G2 > Certification Authority of WoSign > StartCom Certification Authority.
I think the problem might be that the server is only sending the chain up to WoSign cA Free SSL Certificate G2. The browser knows the Certification Authority of WoSign certificate, so it can complete the trust chain. cURL on the other hand only known StartCom Certification Authority, so it can’t complete the chain. Solution: the server needs to send the complete chain.
Confirmed: https://www.ssllabs.com/ssltest/analyze.html?d=bohoomil.com
Chain issues: Incomplete, Extra certs Extra download: WoSign CA Free SSL Certificate G2
The server is actually just sending its own certificate.
(The other problems – cipher suites, exchange problems, etc. – might also be worth looking at.)
And after they are fixed, HSTS could also be nice. HTTPS Everywhere could probably also be told that the issue is resolved when it is.
Thanks for all the tips (some sounds like Chinese proverbs to my ears, though). I'll see what I can do as a non-expert.
Is there any schedule for this? The only not-https repository bothers me.
This seems to still be an issue, but now there is also LetsEncrypt which can automatically configure Apache.
When connecting via https to bohoomil.com using firefox or chrome it complains about the TLS certificate being expired.