I host it off of a gitlab instance and all my other custom domains seems to work just fine except for this one. Leads me to believe it is probably blacklisted. I suspect when i was setting it up I used it to try if the system was working one too many times.
If it is blacklisted how do I get it approved again?
This wonky redirect is almost-certainly the problem if you're trying to satisfy an http-01 challenge: It's a different sort of delegated challenge satisfaction. Neato.
http://jeffreyfreeman.me/.well-known/acme-challenge/test
307 Temporary Redirect
https://git.qoto.org/-/acme-challenge?domain=jeffreyfreeman.me&token=test
404 Not Found
Yep. Same one. So it's not an issue with the execution of the general method. With what software/process are you obtaining your certificates?
http://beta.jeffreyfreeman.me/.well-known/acme-challenge/test
307 Temporary Redirect
https://git.qoto.org/-/acme-challenge?domain=beta.jeffreyfreeman.me&token=test
404 Not Found
It quit nice when its working right, renews automatically indefinitely.
i will need to dig it out of the depths of docker somewhere. that said if you are confident it is this redirect then i think i have a reverse proxy that could somehow be generating it.
NVM, I think this redirect is how gitlab is supposed to work...hmm cant find a reason why it is just this one domailn.. ill go to bed now and dig more in the morning. Thanks so much.
The problem is not the redirect if you have subdomains working that way. Maybe a credential issue related to certifying the apex domain name that doesn't occur with the subdomains.
The gitlab already does DNS validation. I dont think that fixes the problem. In order to use your custom domain you must first verify it, but then it obtains the TLS certificate through the normal way (through challenge)... so unless i misunderstood you that is already used and not relevant.
Other domains that are apex domains using the same gitlab server work however (such as aparapi.com). So if this is true it is somehow effecting only this one apex domain on the server.
Ok it sounds like you two are talking about a different type of DNS validation than Gitlab's builtin DNS validation.
Can Gitlab even do DNS validation? Obviously I would need to add some record to my DNS, which I can do (and have to do for other reasons too). But wouldnt gitlab still need to initiate the renewal and retrieve the cert somehow. Can it be setup to do that? I dont think it can.
There's no need to do so. I was hoping there was additional information associated with the failure for jeffreyfreeman.me. I looked through the tutorial that @webprofusion mentioned, but it's really old and manually driven, so I'm fairly certain that's not how you certified your other domain names. Typically this type of delegation system requires adding domain names to the system to which you are delegating (gitlab in this case). Did you by chance add only *.jeffreyfreeman.me? It is a common misconception that a first-level wildcard also represents the apex domain name (jeffreyfreeman.me). It does not, which is why jeffreyfreeman.me would need to be added separately.
The way gitlab works is that each repo has the ability to push to a branch that represents its static webpage content. When you do this you go into the repo's settings and tell it the branch is a page, and the domain name associated with it (which is verified through an unrelated process). At that point gitlab goes out and fetches the LE cert. So there is no place where I could explicitly state a wildcard domain, each domain is explicitly set on a case by case basis.
Let me try and keep digging to find those logs.. pretty sure they are there somewhere it just would be pretty old.
Do you only set the apex domain name or do you need to set each fully qualified domain name (FQDN)? If it's the latter, did you set the apex domain name?
In each case the full domain name needs to be set. Keep in mind this setup was working and then just stopped renewing. I can send you screenshots of the interface in gitlab for setting the pages, it isnt anything special though.