Wildcard redirects break Let's Encrypt integration
From gitlab!72069 (closed):
The Let's encrypt automatic integration for gitlab pages is not working when using wildcard redirects.
I.e.
/* /index.html 200
in _redirects file for pages.
This happens because https://gitlab.com/gitlab-org/gitlab-pages/blob/5e86747b6287381e2f23afe837ede1820876cf8d/internal/acme/acme.go#L33-L33 checks if project has a file in it, and we handle redirects, so our acme middleware doesn't redirect to gitlab.
I see a few ways of fixing this:
- stop redirecting any
"/.well-known/acme-challenge/*"
files - remove this
if domain.ServeFileHTTP(w, r)
check completely. This was originally done to allow users to manually implement their integration with Let's Encrypt. People were doing this before we had our one integration. - In the API response for domain add
redirect_for_acme_challenges: true
and replaceif domain.ServeFileHTTP(w, r) {
withif !domain.RedirectForAcmeChallenges {
- In the API response return the actually acme challenges like
{acme_challenges: [{path: "/.well-known/acme-challenge/somehting", value: "somevalue"}]}
. Currently, we rely on the main gitlab instance being public and reachable from Let's Encrypt, so we just redirect to it. If we go with the last option, we can get rid of this requirement.
However, last 2 options will also slow down the Let's Encrypt integration, as we update domain config cache not that often.
Actually, I'm(@vshushlin) in favor of the first option - it shouldn't break anything for existing users, as not many people use redirects yet. And it doesn't slow down the Let's Encrypt integraiton.