Why do we slugify this only here, and not for cert?

Is this there to make bash happy? Or is this some standard used by other clients as well? If it's only the former, I'd rather see our shell script being able to handle * (as we put it in double quotes).

This is actually a "feature" of minica and lego. They replace the star with an underscore, so in order to reference the output files I need to do this myself too.

An end user will never see this either, we rename all the certs in /var/lib/acme/ to something more easily referenced. I might add a test which covers having a star in the cert variable to ensure that the scripts always work in that scenario.

Thanks for the explanation! Please add a amsll comment to it next to keyName, so this is understandable.

After a bit of testing, I discovered that if ${cert} contains a * it breaks things in multiple places, most crucially it broke the compilation of the systemd units. I have added an assertion recommending users to use the domain argument as we do in the tests.

Note that this makes regular files (e.g. /var/lib/acme/hydra.nixos.org/fullchain.pem) executable, which is a bit ugly.

chmod -R u=rwX,g=rX,o= "$fixpath"

Thanks for the feedback + the hint. I'll open a PR if no one beats me to it :)

Not that I care a lot anymore, but note that there is a reason why these were added here instead of being generated: If you substitute the test-certs derivation but build the ca-certificates.crt on a different host, you'll get mismatched certificates.

Hm, I don't really follow you on this one? The CA certificates and the test certs are generated in the same derivation now, so they can't drift from each other. My understanding of the cache is that for any one execution of the tests all nodes will use the same nix store and cache and thus it doesn't matter which it chooses from (local build or cache) when setting the security.pki.certificateFiles. Unless I am missing something?

The issue is that the CA certs are copied, so while your machine might have test-certs version A, it might use ca-certificates.crt built (or in this case substituted) using test-certs version B.

edit: To illustrate this a bit better, consider this situation:

local store:

• /nix/store/1234-test-certs - hash: abcd9876

remote store:

• /nix/store/1234-test-certs - hash: dcba9182
• /nix/store/5678-ca-certificates.crt

So if you're going to build the test, you substitute /nix/store/5678-ca-certificates.crt from the remote store and thus get the CA certificate from the test-certs derivation with content hash dcba9182 while the test is actually generating the server certificates from abcd9876.

Ok I follow you now. I had to revise my understanding of derivations, and as the docs highlight the hash is based on the buildInputs, name and output name. And then the chaos you have explained can happen since the output isn't deterministic based on those properties, and caCertificates can drift.

I'm not keen to hard code the certs back in, but there really is no other solution right? I already read back on your commits to see how you tried to solve it before. I was trying to think of something involving builtins.mkHash + builtins.readFile but that still depends on the "broken" certs derivation. If only outputHashMode + outputHashAlgo could be set without outputHash itself, resulting in a generated outputHash based on the cert files.

Ah hang on - cacerts has preferLocalBuild set to true, so surely setting preferLocalBuild for test certs too will ensure consistency?

Ok that's good to know. Putting them in separate files in the repo sounds like a good solution. I'll do that tonight, and I'll keep the minica based generator there as a solution for generating the SSL certs incase they must be regenerated in the future.

@m1cr0man: Hm, one way to address that would be if minica would be fully deterministic when generating keys/certs, which would help in a lot of other scenarios when testing with TLS enabled.

edit: Lemme give this a try and make a PoC.

Okay, here is the working PoC (checked several times with nix-build --check). However implementing this in a sane™ way is not so easy, since Go's crypto library tries to prevent determinism via randutil.MaybeReadByte.

So we either need to copy & paste a deterministic version (which just doesn't use randutil.MaybeReadByte) of rsa.GenerateMultiPrimeKey into minica or "simply" patch go (which I did in the PoC). The latter has the advantage that it would also work if we'd want to have eg. ECDSA certs, while we'd need to create another copy for the former.

Maybe a better way to implement this would be to find a crypto library which doesn't try to prevent determinism and use that to generate the certs/keys.

Of course, another question here is the way we expose this, since we certainly don't want people to use this for other purposes than testing but on the other side I think it's useful to have this generally available for all sorts of tests.

And the last issue - which certainly is a bigger one that's even more prevalent with the hardcoded certificates - is certificate expiry, which minica sets to 100 years for the CA root certificate and to 2 years and 30 days for every server certificate. One way out of this would be if run our VM tests with a fixed time in general, but that's something for another pull request... ;-)

We should really just go back to having a .nix to regenerate the private keys and storing them in the repository. Lots of other tests do the same already.

I agree @emilazy , but not to just immediately drop @aszlig suggestion I think the better course of action there would be to make an issue over on minica (and maybe open a PR? I might try) for a way to deterministically generate test certs.