That is how all CAs authenticate via HTTP & HTTPS.
Do you know how the authentication was being done?
Older clients would prefer HTTPS authentication (TLS-SNI-01) and could also do HTTP and DNS authentication.
While newer clients are no longer "allowed" to use TLS-SNI-01 and now prefer HTTP.
[But are still allowed to use HTTP and DNS - and now also support TLS with ALPN (TLS-ALPN-01)]
To be honest, I have no idea how it worked before. Is there any solution to this problem? Cause Im not the only one having this issue, as there are many other apache svn servers out there.
From what I could find online, it seems that certbot can be used but only in standalone mode.
[which means SVN would have to be stopped]
But it seems like that may NOT be necessary; If SVN is NOT being used on port 80.
You could then run both at the same time.
Which port(s) are you using for SVN?
Can you do without using port 80 (on SVN)?
[Can port 80 reach your server (no ISP block)?]
[What does the SVN vhost file look like?]
so this would require an “empty” vhost configuration, pointing to some random empty directory for port 80? But wouldnt the certbot automatically create a new 443 vhost config, as it was doing it for all other unsecured domains before, and overwrite the svn config during this process?
And stopping the svn for an SSL update every 2-3 months is not an option at all.
Certbot will only create a new 443 vhost config is one was not found that covers that set of names.
It won't automatically overwrite an existing config.
I was proposing to find an option that would NOT stop the SVN.
It's a while since I ran an svn server but I think it relied on Apache to handle HTTP(S) and plugged into it via a webdav interface of some sort.
So it's likely that certbot's apache plugin would work, and is probably what you were using before. If it's recently stopped, it's probably because of this:
Certbot's apache plugin recently switched from using port 443 by default for renewals to using port 80 (since the method it used to use on port 443 is going to be disabled soon). So for that to work, Let's Encrypt must be able to connect to your server on port 80. If you can open the port generally instead of just to one IP address, the renewal may "just work".
That explains a lot, thank you. As you can imagine, the firewall rule is there for a reason, but if one might be able to tell, which IP will do the testing, I could add it.
At the moment, I am using the manual dns method for all of the 12 domains
Certbot’s apache plugin adds temporary configuration during the renewal process, that should (I think) be able to override the IP filtering at the Apache level, just for the special /.well-known/acme-challenge/... URL that needs to be checked by the CA.