New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/acme: update documentation #86347
Conversation
Thanks for writing this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Recommending BIND pains me, but it's good to have a working DNS-01 example :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for writing this together :-) Some comments.
A list of extra domain names, which are included in the one certificate to be issued, with their | ||
own server roots if needed. | ||
A list of extra domain names, which are included in the one certificate to be issued. | ||
Setting a distinct server root is deprecated and not functional in 20.03+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Setting a distinct server root is deprecated and not functional in 20.03+ | |
Support for configuring distinct challenge webroots has been dropped. | |
Challenges are saved from the same folder. |
I had to think two times here what "server root" means.
This was a way to provide an alternative webroot to serve challenges for that specific domain.
Am I right to assume lego doesn't support that anymore, and we put all challenges into the same folder (and nginx for example defaults the per-vhost acmeRoot
option to the same locaiton).
We should also add this to the 20.03 release notes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, no support from lego. I'll add it to the release notes.
nixos/modules/security/acme.xml
Outdated
@@ -10,88 +10,238 @@ | |||
for Let's Encrypt. The alternative ACME client <literal>lego</literal> is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we support more than Let's Encrypt, via security.acme.server
. One could also use Buypass, or an internal ACME server.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that was hangover from the original docs. I'll make it more open about other providers :)
This address is only used for registration and renewal reminders, | ||
and cannot be used to administer the certificates in any way. | ||
</para> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add a note here explaining security.acme.server
too.
nixos/modules/security/acme.xml
Outdated
<xref linkend="opt-security.acme.acceptTerms" /> = true; | ||
<xref linkend="opt-security.acme.email" /> = "admin+acme@example.com"; | ||
services.nginx = { | ||
<link linkend="opt-services.nginx.enable">enable = true;</link> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<link linkend="opt-services.nginx.enable">enable = true;</link> | |
<link linkend="opt-services.nginx.enable"> = true;</link> |
or does this render differently?
I'd personally prefer the <link linkend="…">…</link>
syntax, as used below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah link renders nothing on its own whereas xref puts in the option path. Although, I noticed the close tag was in the wrong place, fixed now.
</para> | ||
</section> | ||
<section xml:id="module-security-acme-configuring"> | ||
<title>Configuring</title> | ||
<title>Manual configuration of HTTP-01 validation</title> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When do we need the manual way?
Doesn't the module system provide a much more convenient way to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel it's good to keep this for 2 reasons, one is so people know how to integrate it with existing setups where maybe they do want to use port 80 for things and have a vhost there, and secondly explaining how the system works so that it can be adapted for other web servers is important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm mostly worried about people just quickly skimming over this, and thinking "OMG, is this complicated". But as the easy setup is just on the same page, it should be fine. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this section. It's always good to show as many example setup as possible. It's in a different section clearly stating this is a manual conf. I think this is fine!
nixos/modules/security/acme.xml
Outdated
certs are overwritten when the ACME certs arrive. For | ||
<literal>foo.example.com</literal> the config would look like. | ||
This is useful if you want to generate a wildcard certificate, since | ||
Let's Encrypt will only hand out wildcard certs over DNS validation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's Encrypt will only hand out wildcard certs over DNS validation. | |
ACME servers will only hand out wildcard certs over DNS validation. |
Nix config. Instead, generate them one time with these commands: | ||
</para> | ||
|
||
<programlisting> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no such /var/secrets
in nixpkgs. There's /run/keys
for nonlocal secrets, and some occurences of/var/lib/secrets
for more persistent ones. I'd propose to use the latter in this example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/var/secrets
is a personal preference, I'll change it to /var/lib/secrets
👍
nixos/modules/security/acme.xml
Outdated
<para> | ||
Now you're all set to generate certs! You should monitor the first invokation | ||
by running <literal>systemctl start acme-example.com.service & | ||
journalctl -fu acme-example.com.service</literal> and watching for errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
journalctl -fu acme-example.com.service</literal> and watching for errors. | |
journalctl -fu acme-example.com.service</literal> and watching for its log output. |
That's a bit pessimistic :-D
Thanks for the solid review @flokli ! I've made those changes now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this, it's super useful <3!
LGTM.
See the comments for a remark and a couple style nitpicks.
A list of extra domain names, which are included in the one certificate to be issued, with their | ||
own server roots if needed. | ||
A list of extra domain names, which are included in the one certificate to be issued. | ||
Setting a distinct server root is deprecated and not functional in 20.03+ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be off-topic for this PR, but on top of this message, could we generate a eval-time warning using the assertion module
nixpkgs/nixos/modules/misc/assertions.nix
Line 21 in b67bc34
warnings = mkOption { |
acmeRoot!=null
here?
Do we plan to backport this commit to 19.09? If not, I think this is safe to assume this option is deprecated and not functional, hence dropping the in 20.03+
part of this message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, maybe it's also time to remove the acme root from this example:
nixpkgs/nixos/modules/security/acme.nix
Line 253 in c9f6e5f
extraDomains = { "www.example.com" = null; "foo.example.com" = "/var/www/foo/"; }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I actually tried doing that back when I did the DNS-01 update, but I couldn't figure out how to add a deprecation warning to a submodule (which is what the certs are). When I rewrite the whole module I'm actually going to add a warning and a rewrite rule to change them to a list.
</para> | ||
|
||
<para> | ||
You will need an HTTP server or DNS server for verification. For HTTP, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will need an HTTP server or DNS server for verification. For HTTP, | |
You will need an HTTP or DNS server to perform the verification. For an HTTP verification, |
Style nitpick, feel free to ignore if you don't like it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the verification is more of a process so a proper noun rather than a concrete noun, personally I think it reads more naturally the way it is.
<filename>.well-known/acme-challenge</filename>. This directory must be | ||
writeable by the user that will run the ACME client. | ||
writeable by the user that will run the ACME client. For DNS, you must |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
writeable by the user that will run the ACME client. For DNS, you must | |
writeable by the user that will run the ACME client. For a DNS verification, you must |
Style nitpick, feel free to ignore if you don't like it.
<para> | ||
Automatic cert validation and configuration for Apache and Nginx virtual | ||
hosts is included in NixOS, however if you would like to generate a wildcard | ||
cert or you are not using a web server you will have to configure DNS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cert or you are not using a web server you will have to configure DNS | |
cert or you are not using a web server you will have to use a DNS |
Style nitpick, feel free to ignore if you don't like it.
</para> | ||
</section> | ||
<section xml:id="module-security-acme-configuring"> | ||
<title>Configuring</title> | ||
<title>Manual configuration of HTTP-01 validation</title> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this section. It's always good to show as many example setup as possible. It's in a different section clearly stating this is a manual conf. I think this is fine!
Thanks everyone! @m1cr0man this can probably also be backported to 20.03, right? |
Yeah, it can. I'll create a backport PR. |
} | ||
# We can also add a different vhost and reuse the same certificate | ||
# but we have to append extraDomains manually. | ||
<link linkend="opt-security.acme.certs._name_.extraDomains">security.acme.certs."foo.example.com".extraDomains."baz.example.com"</link> = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be commented out or moved out of the services.nginx.virtualhost attribute set I think- at the moment it looks like there should be an option services.nginx.virtualhosts.security.acme.certs.extraDomains, which doesn't exist afaic
Motivation for this change
Closes #86114
Revamped the documentation for generating certs as a whole, on top of
adding instructions for DNS validation. I also updated the docs for
security.acme.certs.<name>.extraDomains
since alt webroots are not supported.These docs should be updated again when #83474 is merged, since it is unlikely users
want to set up a whole DNS server just for certificates.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)