To even log in to this forum, I had to allow an exception. When I first tried to log in it gave me a warning that the issuer of the certificate is unknown. Viewing the certificate information, the issuer common name is “Intevation TLS CA 2016” and the organization name is “Intevation GmbH”. The recipient of the he recipient of the certificate is shown as being “wald.intevation.org”
Please fix this issue. I don’t like having to add exceptions to my browser to access HTTPS protected websites. That kind of defeats the purpose of the security provided by HTTPS. However, GPG4Win is a well known project, so I trust that you guys aren’t trying to hack me.
if you are trusting us to provide proper information, you could import our certificate,
see https://ssl.intevation.de/. Intevation is one of the two companies doing the majority of the work for providing Gpg4win.
I didn’t have this problem a few years ago, when I last came to this forum. Not sure what’s different now. Did somebody revoke your HTTPS certificate?
As for visiting the website you just suggested to get a certificate to import, I got this error message from my browser “Hmm. We’re having trouble finding that site.”.
Ok, it went through now. Wonder what happened? Temporary loss of internet connection?
Ok. I imported the certificate, and now it works.
good to know it is working now.
As to your question: What happened?
Web browsers grew more security features, which in general is a good thing, but they sometime communicate it overly cautious to the user and do not consider some other problems of the hierarchical nature of public key infrastructure.
Sooner or later we will overhaul our infrastructure and make the warnings go away, however our focus is more on providing a good product than to chase the browser developments to closely. >:)
Yes, shure, certificate could be imported. But in times of free and by CA trusted SSL certificates (=> LetsEncrypt) available there is no reason for importing ‘private’ ssl certificates. Just my 2 cents…
Wald hosts many project pages, some with foobar.wald.intevation.org, some with dedicated host names, so the certificates have to support at least wildcards, but even better additional SAN entries. The current certificate has about 40 SAN entries, which are not even supported by most commercially available certificates.
We use Let’s Encrypt for some other servers, but as listed on Upcoming Features - Let's Encrypt the ETA for support for wildcard certificates now is February 27, 2018.
Only after this becomes available, we can see if it works for Wald out of the box, or if we need to introduce SNI support, which in itself still has problems today. For example it would no longer be possible to clone Mercurial repositories with the Mercurial version included in Debian jessie, and wget from Debian wheezy LTS doesn’t support this either. But as those distributions will reach their relevance at some point, SNI will become an option (if still needed with Let’s Encrypt).
As with many things in IT: Sometimes the things that easily work in a small setup don’t work in a larger setup.
The SHA256 fingerprint is published on the website https://ssl.intevation.de/ for Intevation-Root-CA-2016.crt .
But inside the Intevation-Root-CA-2016.crt there is a SHA1 fingerprint.
Could you publish the SHA1 fingerprint for Intevation-Root-CA-2016.crt so that users can verify the integrity of your certificate?
I’ve opened an issue with our Administration to publish the SHA1 fingerprint, too.
Makes sense to me but I don’t have access to edit the page myself.