caddy -version)?Caddy 0.10.12 (+88edca6 Wed Apr 11 01:44:19 UTC 2018) (unofficial)
1 file changed, 26 insertions(+)
caddy/caddymain/run.go
Run caddy in the same manner as the previous version (0.10.11)
andrewshinsuke.me {
gzip
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
X-Forwarded-Proto "https"
X-Forwarded-Port "443"
}
root /var/www/andrewshinsuke
fastcgi / /run/php/php7.0-fpm.sock php
rewrite {
if {path} not_match ^\/wp-admin
to {path} {path}/ /index.php?_url={uri}
}
}
customer.pause.pizza {
gzip
proxy / localhost:1001
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
kitchen.pause.pizza {
gzip
proxy / localhost:1002
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
clutchmemes.gilgameshskytrooper.io {
gzip
proxy / localhost:1003
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
chat.gilgameshskytrooper.io {
gzip
proxy / localhost:1004 {
websocket
transparent
}
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
chatbot.gilgameshskytrooper.io {
gzip
proxy / localhost:1005 {
transparent
}
tls [email protected] {
dns namecheap
}
header / {
Access-Control-Allow-Origin "*"
Content-Security-Policy "upgrade-insecure-requests"
}
}
prometheus.gilgameshskytrooper.io {
gzip
proxy / localhost:1007
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
adm.gilgameshskytrooper.io {
errors stdout
gzip
proxy / localhost:1008
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
}
}
#hotel.gilgameshskytrooper.io {
# errors stdout
# gzip
# proxy / localhost:1009
#
# tls [email protected] {
# dns namecheap
# }
# header / {
# Content-Security-Policy "upgrade-insecure-requests"
# }
#
#}
hotel.gilgameshskytrooper.io {
errors stdout
log stdout
gzip
proxy / localhost:8080 {
transparent
}
timeouts none
tls [email protected] {
dns namecheap
}
}
bigdisk.gilgameshskytrooper.io {
errors stdout
log stdout
gzip
proxy / localhost:8080 {
transparent
}
timeouts none
tls [email protected] {
dns namecheap
}
}
clutchmemes.com {
log stdout
errors stdout
gzip
tls [email protected] {
dns namecheap
}
header / {
Content-Security-Policy "upgrade-insecure-requests"
X-Forwarded-Proto "https"
X-Forwarded-Port "443"
}
root /var/www/clutchmemes
fastcgi / /run/php/php7.0-fpm.sock php
rewrite {
if {path} not_match ^\/wp-admin
to {path} {path}/ /index.php?_url={uri}
}
}
Execution Environment: Ubuntu VM on Digital Ocean (Linux: AMD64)
Go Version: go1.10 linux/amd64
cd ~/go/src/github.com/mholt/caddy
git pull origin master
cd caddy
(Add plugins in caddymain/run.go)
go run build.go
./caddy -conf /etc/caddy/Caddyfile -email [email protected] -agree
Similar results to running version 0.10.11
Activating privacy features... 2018/04/10 21:49:55 [chatbot.gilgameshskytrooper.io] failed to get certificate: Time limit exceeded. Last error: NS dns2.registrar-servers.com. returned NXDOMAIN for _acme-challenge.chatbot.gilgameshskytrooper.io.
I'm not exactly sure (all my apps are pretty custom)
Also note, since I never moved the new executable into my path, I still have version 0.10.11 as the default system version. Running this version still work fine (even after version 0.10.12 failed)
This looks like a problem with DNS plugin to me, but I'm not sure.
Any idea what needs to be changed by the plug in?
How sure are you that absolutely nothing about your DNS changed in the last 1-5 months?
I think very sure? In fact, I am still able to use v0.10.11 with no issues. And I only started using Caddy with version 0.10.11
I am definitely not currently using the wildcard feature released in v2
Just updating the executable to use the changes pushed to master for version 0.10.12, and then running the executable in the same manner.
It has nothing to do with which Caddy version, really -- at least I think -- because 0.10.11 may not even be requesting new certificates. 0.10.12 has to, even if your certificates aren't expiring soon, because of the ACMEv2 upgrade. I'm wondering if 0.10.11 will encounter a similar issue when renewal time comes.
Interesting point. I'll try to figure out when my certificates were last updated.
The most recent site I added using v0.10.11 was on Apr 12 (I'm looking at ls -l on the .crt, .json, .key files generated in the /.caddy/acme-v01.api.letsencrypt.org/sites/sitename directory.
$cd ~/.caddy/acme/acme-v01.api.letsencrypt.org/sites/www.gilgameshskytrooper.io/
$ls -l
-rw------- 1 root root 3830 Apr 12 16:09 www.gilgameshskytrooper.io.crt
-rw------- 1 root root 237 Apr 12 16:09 www.gilgameshskytrooper.io.json
-rw------- 1 root root 1679 Apr 12 16:09 www.gilgameshskytrooper.io.key
have not added any sites since this point. Hence, I think my DNS settings should be good to go.
For further notes:
It seems like caddy v0.10.12 did indeed succeed in getting some of the certs for some of my sites. Those certs are dated like April 10th
Hmmm. So it's just that one domain? So strange. I wonder if this is an issue with Namecheap.
Maybe. Right now, I'm retrying version 0.10.12 after deleting the directory of the offending site. But still seems to be stuck on the Activating privacy features... screen. Do you think I hit the rate limit for obtaining certs on just ACMEv2?
I guess if ACMEv2 calls a different server, it would explain why using Caddy v0.10.11 still works while maybe I hit the production limit on using Caddy v0.10.12?
Sorry if I sound like a blabbing imbecile. I'm not entirely caught up to speed on how ACME works.
eeek -- Make sure you use the staging endpoint when testing. If you haven't hit it yet, you might soon.
Basically for the DNS challenge to work, Caddy (via the Namecheap package in an upstream repo) will set a special domain TXT value in your zone file. Let's Encrypt's servers verify that the TXT record is the right value, and issue the domain. The DNS challenge often fails if DNS providers have slow or inconsistent APIs, and we do see timeouts too, sometimes in the several minute range. That is unfortunate, and it's up to your DNS provider to fix.
But would this be different between ACMEv2 and ACMEv1? I've never had this problem on version 0.10.11.
Also, do you think deleting the TXT record in my DNS provider's control panel would fix this?
Couldn't hurt to try. It's supposed to be deleted after the challenge anyway.
Okay. Thanks for all your help. I'll go ahead and close this and try various things (like wait a week in case I hit rate limits).
You won't hit rate limits using the staging endpoint (except in extreme cases) -- so don't bother waiting if you want to debug!