Home Explore Blog CI



nixpkgs

5th chunk of `nixos/modules/security/acme/default.md`
ca767c0ad304c578361b93dfd95779686849baa2c87a4e040000000100000c96
        acmeRoot = null;
      };
    };
  };
}
```

And that's it! Next time your configuration is rebuilt, or when
you add a new virtualHost, it will be DNS-01 validated.

## Using ACME with services demanding root owned certificates {#module-security-acme-root-owned}

Some services refuse to start if the configured certificate files
are not owned by root. PostgreSQL and OpenSMTPD are examples of these.
There is no way to change the user the ACME module uses (it will always be
`acme`), however you can use systemd's
`LoadCredential` feature to resolve this elegantly.
Below is an example configuration for OpenSMTPD, but this pattern
can be applied to any service.

```nix
{
  # Configure ACME however you like (DNS or HTTP validation), adding
  # the following configuration for the relevant certificate.
  # Note: You cannot use `systemctl reload` here as that would mean
  # the LoadCredential configuration below would be skipped and
  # the service would continue to use old certificates.
  security.acme.certs."mail.example.com".postRun = ''
    systemctl restart opensmtpd
  '';

  # Now you must augment OpenSMTPD's systemd service to load
  # the certificate files.
  systemd.services.opensmtpd.requires = ["acme-finished-mail.example.com.target"];
  systemd.services.opensmtpd.serviceConfig.LoadCredential = let
    certDir = config.security.acme.certs."mail.example.com".directory;
  in [
    "cert.pem:${certDir}/cert.pem"
    "key.pem:${certDir}/key.pem"
  ];

  # Finally, configure OpenSMTPD to use these certs.
  services.opensmtpd = let
    credsDir = "/run/credentials/opensmtpd.service";
  in {
    enable = true;
    setSendmail = false;
    serverConfiguration = ''
      pki mail.example.com cert "${credsDir}/cert.pem"
      pki mail.example.com key "${credsDir}/key.pem"
      listen on localhost tls pki mail.example.com
      action act1 relay host smtp://127.0.0.1:10027
      match for local action act1
    '';
  };
}
```

## Regenerating certificates {#module-security-acme-regenerate}

Should you need to regenerate a particular certificate in a hurry, such
as when a vulnerability is found in Let's Encrypt, there is now a convenient
mechanism for doing so. Running
`systemctl clean --what=state acme-example.com.service`
will remove all certificate files and the account data for the given domain,
allowing you to then `systemctl start acme-example.com.service`
to generate fresh ones.

## Fixing JWS Verification error {#module-security-acme-fix-jws}

It is possible that your account credentials file may become corrupt and need
to be regenerated. In this scenario lego will produce the error `JWS verification error`.
The solution is to simply delete the associated accounts file and
re-run the affected service(s).

```shell
# Find the accounts folder for the certificate
systemctl cat acme-example.com.service | grep -Po 'accounts/[^:]*'
export accountdir="$(!!)"
# Move this folder to some place else
mv /var/lib/acme/.lego/$accountdir{,.bak}
# Recreate the folder using systemd-tmpfiles
systemd-tmpfiles --create
# Get a new account and reissue certificates
# Note: Do this for all certs that share the same account email address
systemctl start acme-example.com.service
```

Title: Using ACME with Root-Owned Certificates, Regenerating Certificates, and Fixing JWS Verification Errors
Summary
This passage provides guidance on using ACME with services that require root-owned certificates, like OpenSMTPD, using systemd's `LoadCredential` to manage file ownership. It also explains how to regenerate certificates quickly if needed, such as in response to a vulnerability, by cleaning the state of the ACME service. Finally, it addresses the 'JWS verification error,' suggesting deleting the corrupted accounts file and re-running the service to regenerate credentials and certificates.