PBS, PVE, caddy reverse proxy, acme.sh

[danradom]

Am I stuck changing the fingerprint every time the cert renews? I don't want to proxy all my backup traffic through the caddy proxy, so i'm not using the hostname for the PBS storage in PVEs.

 

[Chris]

Hi,
if you use a self-signed certificate on the PBS, then yes. Every time the finger print changes it needs to be adapted on the client (PVE) side. The question then is why do you update the certificate that frequently?

If you are using certificates generated by an external trough acme.sh (as the title of the thread implies), you will however not have to provide a fingerprint at all, given that these can be validated by the certificate chain. In that case simply leave it emtpy on the PVE side.

 

[danradom]

If I use the IP, I need the fingerprint. If I use the DNS name, wont all PBS traffic go through the proxy?

 

[VictorSTS]

If I use the IP, I need the fingerprint

Of course, because even if the cert comes from a verifiable CA, it's CN does not contain the IP. It's the same as if you were accessing your PBS using a different host name.

wont all PBS traffic go through the proxy?

Yes, it will. That's what you setup a caddy for, isn't it? To get it to proxy request and provide automatic SSL cert renewal. Just use it and if it becomes a bottleneck optimize it or switch to any other reverse proxy that may suit you.

 

[Relleuq]

I had issues with certificate renewal too when I used a dynamic IP, and DNS challenges failed because of rate limits and bad IP reputation. I switched my outbound traffic through https://froxy.com/en/residential-proxies and the ACME requests started working fine. It seems like their wide IP pool helped bypass the DNS provider's limits without getting blocked.