Certificate Issuance Issues

#1

I’m trying to add two more certificates to my app for IPv4-only and IPv6-only hostnames.
Let’s assume I have a good reason to do this because the only control I have
over clients is the name they hit to.

While “v6” one succeed without any fuss, the “v4” one is still waiting for an issue.

I tried deleting it and adding again (hence the difference of 1 hour between them).

% flyctl certs show v6.bdd.fi -a bdd
The certificate for v6.bdd.fi has been issued.
Hostname                  = v6.bdd.fi
DNS Provider              = googledomains
Certificate Authority     = Let's Encrypt
Issued                    = ecdsa,rsa
Added to App              = 5 hours ago
Source                    = fly

% flyctl certs show v4.bdd.fi -a bdd
The certificate for v4.bdd.fi has not been issued yet.
Hostname                  = v4.bdd.fi
DNS Provider              = googledomains
Certificate Authority     = Let's Encrypt
Issued                    =
Added to App              = 4 hours ago
Source                    = fly

You are creating a certificate for v4.bdd.fi
We are using Let's Encrypt for this certificate.

You can configure your DNS for v4.bdd.fi by:

1: Adding an CNAME record to your DNS service which reads:

    CNAME v4. bdd.fly.dev

For Let’s Encrypt to issue the cert, I guess you’re using DNS-01 challenge, hence the presence of _acme-challenge CNAME I needed to define under domain apex. So it should work as I already have this—and it did work for v6.bdd.fi.

% dig +noall +answer txt _acme-challenge.bdd.fi
_acme-challenge.bdd.fi.	4	IN	CNAME	bdd.fi.xdjk.flydns.net.
bdd.fi.xdjk.flydns.net.	44	IN	TXT	"89IeLuRvCOicqMXEpS4GYOZY5BpDiyD1z2Gb8Cu2RCg"

Due to the single address family needs I cannot defined a CNAME from these subdomains to the <app>.fly.dev name, but below I verify they’re pointing to the respective addresses of the app.

% [[ $(dig +short aaaa bdd.fly.dev) == $(dig +short any v6.bdd.fi) ]] && echo same
same
% [[ $(dig +short a bdd.fly.dev) == $(dig +short any v4.bdd.fi) ]] && echo same
same

There isn’t any logs for me to debug and understand what is not working out.
I’d appreciate any help.

#2

We do ALPN challenges when an AAAA record is present, so that’s why v6.bdd.fi works.

v4.bdd.fi needs its own acme challenge entry, though: _acme-challenge.v4. This is not obvious from flyctl, but if you look at it in fly.io/apps/ you’ll see better instructions.

If I were you, I’d just add *.bdd.fi to your app.

#3

Ah. Thank you very much.

I was reading RFC 8555 and despite the clear example of ‘www’ there I wrongly assumed equivalence for all the subdomains. Though it’s not. I re-read after your answer assuring me I misunderstood the requirement.

Well, would you look at that. I legit didn’t know about this interface at all. I don’t think I came across it anywhere in the docs. Somehow didn’t notice it when I logged in again to add 2FA. I just saw “Account” link up there.

image
image800×426 58.8 KB

Wildcard even at one level up is not something I want to trust to third-party for now. Just to make sure I don’t mess this up, I even added issuewild ";" CAA entry to DNS. Otherwise I think you’re right, this is an appropriate choice for most users, also less CT Log noise (2 certs (rsa & ecdsa) per subdomain plus their 2 precerts)

Thanks again for the pointers.

1 Like
#4

That’s kind of funny, actually, I didn’t realize how hard-to-find we made our UI. The entire onboarding process is CLI first, which is good, but we have neat graphs we should show off!

1 Like
#5

Another quick link fix from web.fly.io is the “Apps” link pointing to web.fly.io again. Maybe that can also send people to fly.io/apps

image
image1608×954 143 KB

#6

Try fly dash - to go straight to an apps dashboard in the ui
and fly dash metrics - to go straight to the neat graphs.

1 Like