The client lacks sufficient authorization - 404 - SVN domain cannot serve a .well-known directory


#1

So why does the new certbot client have to issue some sort of owner-ship auth with the help of some file?

I have a SVN server running, so it is impossible to serve that file, whatever the client wants to place in whatever directory.

How was that problem handled by the old letsencrypt client? Because that domain is secured via LE for some years now.


#2

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)]


#3

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.


#4

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?]


#5

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.

The config of apache svn is standard, like in that tutorial: https://help.talend.com/reader/5r9QMxelU5pRCZnPEI0VcQ/dgHq5LUSMajI3cp1~lp~IQ


#6

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.


#7

damn, svn needs Port 80 AND port 443, because of one special client, so access to port 80 is only allowed for one IP by firewall rule.

So there is no other way for letsencrypt? Is there a way to escalate this issue to the devs?


#8

Can you insert a (reverse) proxy?

LE also supports DNS-01 validations.
Will the SVN support any other validation methods?


#9

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”.


#10

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


#11

Sorry, but that won’t be possible.

Could you whitelist the special client in your Apache config rather than the firewall?


#12

what would change, if apache is doing the IP-filtering? Because this vhost will still be reachable over a single IP.


#13

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.


#14

Ive tried it that way, but receive the same error as before.


#15

Exactly the same error? Then the port is probably still closed/filtered in your firewall?


#16

yes, exactly the same. Ive cleared the firewall rules, there is nothing left, the only place now is the apace config.


#17

Could you post the exact error message here?


closed #18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.