The console's certificate
The installer gives the console a self-signed certificate, so browsers warn the first time. Replace it with one your browsers already trust: from a certificate company (DigiCert, Sectigo, GoDaddy and the like) or from your own certificate authority (Active Directory Certificate Services, for example). Nothing restarts, and agents are not affected: they connect to Salt, not to this certificate.
To open it: choose Administration > Certificate. Everyone can see the certificate in use; admins change it.
What it shows
The names the certificate covers, who issued it, when it is valid, its key type, its SHA-256 fingerprint, and how many days are left. It also warns when the certificate does not cover the address you are using right now, when it is self-signed, and when it expires within 30 days. From 30 days before it expires, the console's attention banner and your alerts say so too.
Get a certificate: create a request
Most certificate companies and company certificate authorities ask for a certificate signing request (a CSR).
- Under 1. Need a certificate? Create a request, list the names people use to open the console, one per line: its DNS name, and its IP address if people use that. The first is the main name.
- Optionally give your organization, and choose the key type: RSA 2048 (accepted everywhere), RSA 3072 or 4096, or ECDSA P-256 or P-384.
- Choose Create request, then Download .csr or Copy, and send it to your certificate company or certificate authority. For Active Directory Certificate Services, use the Web Server template.
The private key for the request is made on the server and never leaves it. The request waits until you install its certificate; creating another request replaces it.
Install the certificate
Drop the files on 2. Drop the certificate here, or click it to choose them:
| What you have | Drop |
|---|---|
| A certificate for a request made here | The certificate file (.crt, .cer, .pem, .der) and the issuing certificates if they came separately, or the .p7b file |
| A certificate and its private key from elsewhere | The certificate file and the .key file (the key must not be protected by a password) |
| A .pfx or .p12 file | The file, then type its password |
Gardience reads them at once and shows what would be installed: the names, the issuer, the expiry, and where the key comes from. It refuses a certificate that is expired, not valid yet, uses an RSA key under 2048 bits, does not match the key (dropped or from the request), or a request file dropped by mistake, and says why. It puts the server's certificate first and the issuing certificates after it, and leaves out the root, which browsers already have.
Choose Install certificate. The console switches to it within about 10 seconds, without a restart. Reload the page to see the new certificate in your browser.
Go back
The certificate in use before is kept. Go back to the previous certificate switches to it, and choosing it again switches forward. Every request, install and go-back is in the audit log (tls.request_created, tls.installed, tls.reverted).
How it is protected
The console only reads its configuration. Creating a key and installing a certificate are handed to the config keeper, which has no network access and is the only process that writes the configuration; it checks every file again before writing. The private key is stored readable only by its owner. nginx loads the new pair only after its own configuration test passes, so a pair that does not work is never served and the one in use keeps working.
Related
- Install the server (
--tls-certand--tls-keyat install time) - Users and roles