When a client connects to the server (Linux Server / Windows Client in this case) it is required to enter the fingerprint of the servers ssl cert. That fingerprint can be shown using the command:
openssl x509 -in /etc/letsencrypt;live/somedomain.com/fullchain.pem -noout -fingerprint -sha256 | sed 's/://g' | cut -f 2 -d =
However, the current letsencrypt policy is to renew that cert every 90 days which will immediately change that fingerprint. Client backups attempting to connect to the server will be met with a rejection message like authentication handshake failed: can't find certificate matching SHA256 fingerprint
There is another post on this with no solution provided
This is really an urgent situation as it breaks all clients once the cert is naturally modified.
The only solution I am aware of at present is to manually remove and recreate the link to the repository on the client. If I have 50 customers and their client PCs and they all regularly stop backing up that’s a big problem.
So the million dollar question: "How can I most easily update the fingerprint on the Windows client so backups are not disrupted - or is there a way to auto-update the fingerprint on the client?
What sayeth the group?
Use your own private key when requesting cert from letsencrypt. This way they only sign your key and fingerprint should stay the same.
I am just now able to get back to this. Thank you for weighing in on this. It seems an important issue.
We use a wildcard cert for our domain. So the privkey for say backups.ourdomain.com is the same for many other of our subdomains.ourdomain.com
We would not want a single application to dictate this privkey.pem policy. I have also run it by ChatGPT for an opinion and it does expose some real concerns when never rotating a privkey.pem file in a business environment:
ChatGPT:
Yes, reusing the same private key (privkey.pem) across multiple certificate renewals introduces potential risks and trade-offs. Here are some considerations:
1. Key Compromise Risk:
- If the private key is ever compromised, reusing it across renewals means that an attacker can potentially decrypt future traffic even after the certificate itself is renewed. By rotating private keys (generating new ones), you limit the window of exposure if a key is compromised.
- Best practices in cryptography recommend rotating private keys periodically to minimize the risk from such compromises.
2. Forward Secrecy Concerns:
- Many modern systems rely on Perfect Forward Secrecy (PFS), which ensures that even if the private key is compromised, past communications cannot be decrypted. However, reusing the same private key may reduce the effectiveness of PFS, especially in certain older configurations or environments where PFS is not properly enforced.
3. Compliance and Security Audits:
- In some industries or environments (e.g., financial or government), compliance standards or security audits may require regular private key rotation. Reusing a private key might not meet the necessary security standards or requirements.
4. Potential Impact of Weaknesses in Key:
- If your private key was generated using a weak method, reusing it magnifies the problem. Key generation algorithms could potentially have vulnerabilities (e.g., certain random number generators used during key generation). By reusing the same key, you might be propagating these weaknesses indefinitely.
5. Trade-Offs in Renewals and Automation:
- Reusing a private key can simplify certain workflows (like certificate pinning or fingerprint checks), which is likely why you’re considering this option. However, this convenience comes at the cost of potentially reducing security if the same key is used over extended periods of time.
So if the fingerprint is just being used as a credential check it seems this validation requirement is a recipe for failure. If I play this situation through with an example of 50 servers with 5 clients each then their auto renewed cert (every 90 days) will immediately stop backups from functioning since the fingerprint will change. The solution at present seems to have manually detach each client from their repository and reattach it with the new fingerprint. This would be a nightmare every 90 days.
Am I missing something ?
I think I am just now learning that entering a server fingerprint on the client side is not even a required item… That would be a relief 
Would anyone like to confirm that.
My domain is protected by /etc/letsencrypt/live/mydomain.com and I am pointing to those in my systemd server startup command. Perhaps that’s the end of it ?