@madfordmac Additionally this feature made it to Canary release if you want to test it out.
So I installed the canary on a new server that hadnāt run backups before. (Iām a little nervous about using the canary on something where I might need the backup.)
I figured Iād try it without providing a hash first to see if the other fix solved it: nope. So I generated a hash with openssl x509 -fingerprint -noout -in root.crt and put it (sans colons) in accept-specified-ssl-hash in default options. Still as capital letters, if that matters. And I verified with openssl s_client that nginx was serving all 3 certificates. Still no love. I have the same behavior of a ā2 Warningsā alert box, but no warnings in the log.
2 other quick things:
- The ānewā user interface in the canary doesnāt load. Have to manually put in the old /ngax/index.html path.
- āValidatingā a certificate by matching its hash isnāt as secure as doing proper validation. Anyone that can load the endpoint can see the existing certs and then has all kinds of time to engineer something else that matches the hash. Itās just a sha1 hash for which there are working hash collision exploits. Full public key cryptography signatures are more secure.
Still as capital letters, if that matters
It is case insensitive, but without separators neither : nor -
Can you confirm you tried that hash without separators. I tried myself and adding the root certificate hash worked. The certificate date still has to be valid though.
āValidatingā a certificate by matching its hash isnāt as secure as doing proper validation.
Yes, the idea of adding a manual hash to accept it implies the user is willing to override the default certificate validation and is aware of consequences.
Correct, I have the hash entered without any separators. All 3 certificates are still valid, and I have double-checked the hash is correct, both with openssl x509 -fingerprint and openssl x509 -outform DER | sha1sum -.
I did an strace on the server process while I ran a backup, and I think it might be using /etc/ssl/certs/ca-certificates.crt as the list of trusted certificates. That should be ok. My root is in there, and I can pass that file to curl --cacert and my endpoint validates. Iām almost wondering if there is some sort of compatibility problem. My root and intermedate certs are sha256 signatures with 4096-bit keys and the leaf cert for that endpoint is a sha512 signature with a 2048-bit key. Both the 4096-bit keys and the sha512 signature are stronger than whatās in common use right now. Maybe the SSL library isnāt supporting one of those??
Should we add a simple "remove all : and - characters from the hash, so the user does not have to guess the format?
Absolutely, that will be great. Also good to mention on the documentation.
Closing the loop for future searchers: I gave up and switched to a Letās Encrypt certificate for my reporting endpoint so itās in the default trust for Duplicati. I still wonder if this isnāt a compatibility problem and not a chain of problem, but the Letās Encrypt certificate solves it either way.
1 Like