Certbot Nginx Gentoo wildcard has a bug

[9peppe]

@Osiris

what is the exact problem?

Indeed, there was something I wasn't getting there.

[twork]

Staging environment: understood. My "only host" has plenty of test instances in my virtual basement. Carrying on:

@Osiris

So you can continue with getting a certificate. What's not working about that?

My understanding is that -- whether we use Certbot or not -- the key format varies between a "default" and a "wildcard". Certbot's role is, in part, to relieve us from having to understand all those (openssl? also other?) details.

So, either Certbot just doesn't handle *-keys over Gentoo, maybe because it depends on snapd, in which case I need to educate myself in its absence; or, Certbot will work here but I need to give it the appropriate command variables, which I won't know until that page is updated. (Or, someone educates me.)

Or, I can use some program in place of Certbot. On the acme-tiny README, I find:

# For multiple domains (use this one if you want both www.yoursite.com and yoursite.com)
openssl req -new -sha256 -key domain.key -subj "/" -addext "subjectAltName = DNS:yoursite.com, DNS:www.yoursite.com" > domain.csr

That line has those two host entries, DNS:yoursite.com and DNS:www.yoursite.com. When those are specified, it causes me to wonder: would there be a different format in the case of *.yoursite.com? I.E., is there some way to specify the wildcard?

Let's educate me: in...

$ man openssl

...I find no reference to "-subj", "-atdext", or "AltName" at all; I still don't have any way to assert, in advance, "*.whatever.com".

So my question boils down to: when requesting a cert, how do I refer to a wildcard instead of some list of specific host names?

I'm still guessing that I can avoid requesting a cert every time I need to refer to some new name on my box. I just don't know how to tell the cert provider that I want that enabled.

[twork]

@Osiris

@twork

Installation isn't the issue. Configuration is. nginx is running fine, holds multiple environments, but needs to be told to associate specific names (environments) according to a specific key, the hosting of which is...

Sounds complicated.

Only because of the way I described what every proxy-based web server does this. There's nothing unusual about my setup, except that I'm doing it on a Gentoo VM. Praise be, all that.

[rg305]

@twork

Fine, I thought:

https://host.name/foo/wiki/
https://host.name/bar/wiki/
https://host.name/[...]/wiki/

But, it turns out, the chosen wiki doesn't like to work that way. It really, really wants to expect:

https://foo.host.name/
https://bar.host.name/
https://[...].host.name/

Why can't you just proxy the first set [https externally] to the second set [http internally] ?
You wouldn't need more than just the one external cert.

[twork]

@rg305

Why can't you just proxy the first set [https externally] to the second set [http internally] ?
You wouldn't need more than just the one external cert.

That was how I started the project. It turns out not to work in this case.

For example, suppose we have two instances of the wiki package, "whatever.com/foo/" and "whatever.com/bar/"; a user is interested in the "/foo/" instance; and the user wants to enter something new. In TiddlyWiki, it handles new entries by offering a unique path name: "new entry, new name". So suppose my server has multiple instances:

https://whatever.com/foo/
https://whatever.com/bar/

TiddlyWiki's way of handling any reference to some new path is to assume it'll be based under "/". It doesn't handle the case of multiple instances, each given its own name. Instead, it assumes that there will only be one instance under any given host name.

Old-style virtual site names are fine. So if our web server has,

https://some.site/
https://some-other.site/

...we have to assume, like web servers do, that each site refers to some independent, maybe not-mutually-friendly, operation. So, each virtual web server does refer to some specific path within the OS. It just doesn't handle having multiple instances of itself being given their own name.

[rg305]

@twork

each wiki instance needs its own fully-defined name.

And...
Why not just do that internally (on the system).
But externally, it can be referenced/accessed any way you see fit.

[rg305]

Example only. Not provided as working code.

Essentially, the idea is to use one additional location section for the subdomains, like:

location ~^ /(?<subdomain>)$/wiki {
    proxy http://$subdomain$.local.site/wiki;
}

[where "<subdomain>" is a variable that is updated from the URL path and then used to complete the FQDN in the proxy request]

Example only. Not provided as working code.

[twork]

@rg305

Why not just do that internally (on the system).
But externally, it can be referenced/accessed any way you see fit.

I tried that. Maybe I did this wrong, but, as far as I can tell, the app refers to any new entry by calling the server by a path under the root, regardless of the path called for. I don't find any way to rename,

https://myhost.com/foo/new-thing.html

...to specify:

/host/internal/foo/new-thing.tid

Whenever this app is called under any path that does not already exist, it returns by a reference under "/". When the web server finds some un-handled entry there, it defaults to index.html.

There may be a way within the wiki's process to deal with that. I've tried, with help from the wiki's community, but what we tried kept hitting that specific problem. The solution was to specify hostname to instance, thus, its own A record.

[twork]

@rg305

location ~^ /(?<subdomain>)$/wiki {
    proxy http://$subdomain$.local.site/wiki;
}

...may be the bit of code that I/we couldn't find. I'll try again with that. Thanks.

[twork]

Brief update: that location section is roughly equivalent to what I've been doing. The problem is still: under some circumstances, TiddlyWiki refers to / instead of the path it was called from.

That said, I can't find a specific case of the problem right now, so I'm going to drop it until it comes around again. But, it'd (still) be nice to have that page of the cert docs changed.

[Osiris]

@twork

My understanding is that -- whether we use Certbot or not -- the key format varies between a "default" and a "wildcard". Certbot's role is, in part, to relieve us from having to understand all those (openssl? also other?) details.

So, either Certbot just doesn't handle *-keys over Gentoo (…)

Where do these "keys" come from what you talk about?

With Certbot, the only difference between a normal certificate and a wildcard certificate is that you'd put *. before the hostname as the domain name input. Nothing related to keys..

(And of course, due to restrictions of the Certificate Authority and CA/B Forum BR you need to use the dns-01 plugin, but that you were already doing.)

[9peppe]

@twork

Let's educate me: in...

$ man openssl

...I find no reference to

OpenSSL has several subcommands and each of those has its own manpage. You're looking for

man openssl-req

https://www.openssl.org/docs/manmaster/man1/openssl-req.html

[Osiris]

I'm not sure if "education in OpenSSL" is warranted at this time. I've got the feeling that we shouldn't begin with that for the following reasons:

• It's hard enough to "debug" the most simple things in this thread it seems. E.g., I have yet to see any Certbot output to begin with...
• OpenSSL isn't necessary to get a Let's Encrypt certificate;
• OpenSSL is relatively "higher level" stuff, not something a novice should begin with.

[9peppe]

I agree. My aim wasn't to teach openssl, it was more to teach man

Because not knowing how to use openssl is fine. But at the very least you should get an helpful librarian telling you where the books are.

[Osiris]

In that case let's hope the librarian isn't asked to spell out every word in the book

Also, the book isn't worth reading yet currently I think, as stated earlier.

[9peppe]

I agree, there's no reason to read that book right now.

But when somebody asks for a book, I don't stop and think/ask if they really need it.

[Osiris]

@9peppe

But when somebody asks for a book, I don't stop and think/ask if they really need it.

It's a good thing to ask I believe

[twork]

@Osiris

@twork

So, either Certbot just doesn't handle *-keys over Gentoo (…)

Where do these "keys" come from what you talk about?

I recognize that the cert is what Certbot (et al.) will see during any exchange. I tend to use the word "key" in reference to the whole thing, cert and secret. I'll try to be more consistent.

@Osiris

With Certbot, the only difference between a normal certificate and a wildcard certificate is that you'd put *. before the hostname as the domain name input. Nothing related to keys..

The issue I started out with, you'll recall, was a bug in the documentation which had left me confused. "Certbot Nginx Gentoo wildcard has a bug".

Having now learned that there's no significant difference between the default and the wildcard, I ran certobt, found that a domain I'm in the process of setting up has been registered, and so forth. All is well with my system. Thanks for the clarification.

That aside, since it came up: I remembered the specific problem I've been having with TiddlyWiki which has made it necessary to give each instance its own DNS name. At the middle of that thread:

"[N]ever had any success proxying to a directory"

Briefly: typical usage would not be a problem -- read pages, write pages, all fine -- but we run into failures when we try some variation of privileges between users across different instances of the wiki. That's when the fix is to run each instance of the wiki in its own root. So, multiple instances means multiple roots, so, multiple names.

[Osiris]

@twork

I recognize that the cert is what Certbot (et al.) will see during any exchange. I tend to use the word "key" in reference to the whole thing, cert and secret. I'll try to be more consistent.

Then I still don't understand what you meant by the following:

@twork

Certbot just doesn't handle *-keys over Gentoo

Could you perhaps clarify?

Also, I still have no clue what so ever in which part of the process you currently are. You've said you already installed the certbot-dns-cloudflare plugin using my overlay, right? And later you found out you didn't have the certbot-nginx plugin installed, but you probably have that installed now too, right?

So where is your current problem? Getting a (wildcard) certificate? Or installing an already issued certificate into nginx? Because these two things can be separate things.

[twork]

@Osiris

@twork

Certbot just doesn't handle *-keys over Gentoo

Could you perhaps clarify?

That was a reference to the initial question that posted this thread, not the certbot process itself. Those questions have been answered.

To be clear: the issue I posted about to begin with was in the

@twork

$ sudo emerge -av -<PLUGIN> <- to be clear: don't do this!

...and,

@twork

$ sudo emerge -av -cloudflare <- to be clear: don't do this!

...entries, at,

Certbot Instructions | Certbot

That was quickly posted as a bug, hooray! The questions I had around that have been answered, also hooray.

@Osiris

So where is your current problem? Getting a (wildcard) certificate? Or installing an already issued certificate into nginx? Because these two things can be separate things.

Yep. My question was answered around the "wildcard" entry ("safe to ignore" at least in my case), and once that was cleared up, I was able to verify that my nginx setup is fine.

Thanks again, and sorry for any noise I caused.