Privacy and security - how the toolkit handles private keys
The aethercert Toolkit runs entirely locally: no account, no telemetry, no upload. Where private keys are created and kept, what touches the network, and what is stored.
The toolkit is built on one rule, the same one the aethercert platform keeps: private keys never leave the machine they were created on. Everything else on this page follows from that.
Nothing leaves your computer
- No account, no sign-in, no licence key.
- No telemetry, no usage statistics, no crash reports.
- No update check. The toolkit makes no network connection you did not start.
The connections it does make are the ones a tool needs:
| Action | Connects to |
|---|---|
| Certificate scanner, Security scan | The hosts and ports you entered. The security scan also sends one HTTP request for the security headers. |
| Sign code with a timestamp | The timestamp service you chose. Only a hash of the signature is sent, never the file. |
Where private keys live
| Key created as | Where it is | Who can read it |
|---|---|---|
| Windows key store (Create CSR default) | The Microsoft Software Key Storage Provider of this user or this computer | Windows. The key never enters the toolkit's process; Windows signs with it. A key created non-exportable cannot be read out by anyone, including the toolkit. |
| Key file | The toolkit's memory until you save it, then only the file you chose | Whoever can read the file - encrypt it (PKCS#8, AES-256, PBKDF2) unless a server cannot read encrypted keys. |
| Imported from a PFX | The Windows store you imported it into, exportable or not as you chose | Windows. |
A key that exists only in memory is gone when the app closes. Leaving Create CSR or closing the app with such a key asks first, because a certificate issued for its CSR would be unusable.
How the Windows store is driven
The certificate store, the key store and code signing are driven through Windows' own
components (CNG, Set-AuthenticodeSignature), with one fixed PowerShell script per task.
Every value - file names, thumbprints, passwords - goes in on standard input, never on a
command line, so nothing appears in the process list or a log, and nothing a user enters can
change the script.
When a key has to move between the toolkit and the store (importing a key file, exporting a PFX), it travels only between the app and that local PowerShell process, inside a PKCS#12 encrypted with a one-time random password.
Windows keeps its own protection: keys marked not exportable, keys on smart cards, TPMs and HSMs stay where they are.
What the toolkit does not do
- It never installs a root certificate on its own. An import puts intermediates into Intermediate Certification Authorities and skips any root; trusting a root stays a decision for the administrator.
- The desktop app never overwrites an existing file when exporting or converting;
actkdoes so only where you pass--force. - It never writes key material into a report, an export, the clipboard or a log. Copy PEM copies the public certificate only.
What is stored on disk
Settings live in %APPDATA%\com.aethercert.toolkit\settings.json. For each open certificate
request the file holds the common name, the SHA-256 of the public key, and where the key is
- a key container name in the Windows key store, or a file path. Never the key itself. Requests older than 400 days are dropped.
Verifying the toolkit itself
The Windows binaries are Authenticode-signed, and every download has a SHA-256 checksum beside it. See Verify the download.