- 6 minutes to read

Secret Management with Automatic Certificate Handling

New 7.x

Take control of secret management and certificate automation with Nodinite. On this page, you will:

  • ✅ Eliminate manual certificate provisioning and renewal
  • ✅ Secure secrets using industry-standard cryptographic protocols
  • ✅ Automate certificate lifecycle and renewal
  • ✅ Store secrets securely using the operating system’s certificate store
  • ✅ Configure expiration and renewal thresholds for peace of mind
flowchart TD A[Application Startup] --> B{Certificate Exists?} B -- Yes --> C[Load Certificate from Store] B -- No --> D[Generate New Certificate] D --> E[Store Certificate in OS Certificate Store] C & E --> F[Encrypt/Decrypt Secrets] F --> G[Monitor Expiry & Renewal] G -- Expiring --> H[Auto-Renew Certificate] H --> E

This diagram shows how Nodinite automatically manages certificates and uses them for secret encryption and decryption, including renewal and monitoring.

Encryption Overview

Nodinite uses a hybrid encryption approach to secure sensitive configuration data, such as passwords and connection strings. This method combines the strengths of both symmetric and asymmetric encryption to provide robust security.

sequenceDiagram participant User as User/Service participant App as Nodinite Application participant Cert as Certificate Store participant Secret as Secret Data User->>App: Request to store secret App->>Cert: Retrieve encryption certificate App->>Secret: Encrypt secret with certificate App->>Cert: Store encrypted secret User->>App: Request to access secret App->>Cert: Retrieve decryption certificate App->>Secret: Decrypt secret with certificate App->>User: Return decrypted secret

This diagram illustrates the process of encrypting and decrypting secrets using a certificate stored in the operating system's certificate store.

🔐 Configuration Settings for Secret Encryption

Configure encryption and certificate-based key management in your application using the following settings:

Field Label Default Value / Example Type Description Remarks / Gotchas / Links
Encryption Algorithm AES256-RSA-OAEP Dropdown Select the encryption algorithm used to protect secrets. This defines how the data is encrypted (symmetric) and how the encryption key is secured (asymmetric). ✅ Follows hybrid encryption best practices.
🔗 Understanding RSA-OAEP
🔐 Make sure all components consuming the secrets support this algorithm.
Certificate Store Location Windows Certificate Store Dropdown Choose where the app should store or look for certificates. On Windows, the certificate is saved under the Personal store of the service account running the app. Store location may vary on Linux/Containers.
🔗 Microsoft Docs: Certificate Stores
📌 Only Windows is currently supported.
Automatically Manage Certificate Enabled (Checked) Checkbox When enabled, the app will generate and manage the certificate lifecycle automatically. No manual certificate creation or import is needed. ✅ Recommended for most users.
⚠️ Auto-renewal requires write access to the certificate store.
🔐 You are responsible for trusting the auto-generated certificate if used across services.
Subject Name (CN) CN=Nodinite.PROD.XYZ.AutoGeneratedCert Text The subject name for the generated certificate. It should be unique to avoid conflicts. 📌 Avoid using generic names like "Nodinite".
💡Including the environment name helps differentiate certificates in multi-environment setups.
NOTE: The 'Automatically Manage Certificate' option must be checked
NOTE: Subject name must start with CN=
Key Size 2048 (minimum recommended) Dropdown Select the size of the key used in certificate generation. Larger keys offer more security but may affect performance. 🔐 2048-bit is considered secure today.
🔗 NIST Key Management Guidelines
🚫 Avoid using 1024-bit or lower.
🚫 Avoid using 7680-bit or higher.
Validity (Days) 365 Numeric (positive integers only) Number of days the generated certificate will be valid before expiration. 🕒 Long validity can reduce renewal overhead but increases risk if not rotated manually.
📌 Renewal behavior depends on “Expiration Threshold Days.”
Expiration Warning Threshold (Days) 30 Numeric (positive integers only) When the certificate is this many days from expiration, the app will consider it "about to expire" and may trigger automatic renewal (if enabled). 🛎️ Useful to prevent downtime due to expired certs.
🔐 Make sure alerting/renewal logic is functioning correctly.
💡Use the Nodinite Windows Server Monitoring Agent to Monitor the expiry of the Windows Certificate

Critical Change: Service Account Passwords and Secret Encryption

Prior to Nodinite v7, changing the password for a service account would break the encryption and decryption of configuration files and secrets. This limitation required administrators to re-enter all secrets and passwords whenever a service account password was changed, increasing operational risk and complexity.

Starting with Nodinite v7, you can change service account passwords without breaking encryption or decryption of configuration files and secrets. This improvement streamlines maintenance, supports security best practices, and reduces downtime.

For details, see How to set Logon as a Service right.

Tip

If you still use Nodinite v6, update using the Updating from v6 to v7 guide to transition your secret management and certificate handling settings properly.

Eliminate Password Management with gMSA Accounts

Nodinite v7 supports Group Managed Service Accounts (gMSA), which provide automatic password rotation every 30 days without any manual intervention:

Important

Nodinite v7+ Required: gMSA accounts are only supported in Nodinite v7 and later. Nodinite v6 and earlier versions do NOT support gMSA accounts and must use traditional service accounts.

✅ gMSA Benefits with v7 Certificate Encryption:

  • Automatic password rotation - Active Directory rotates the password every 30 days automatically
  • No certificate migration needed - Password rotation does NOT break encryption or require certificate moves
  • Enhanced security - Password is never known or stored by administrators
  • Zero service downtime - Password changes happen transparently without service restarts
  • Simplified compliance - Automatic rotation meets security audit requirements

How It Works:

  • gMSA accounts use the LocalMachine certificate store instead of user profile stores
  • Nodinite automatically detects gMSA accounts and configures the appropriate certificate store
  • When the password rotates, the certificate remains accessible - no re-encryption needed
  • All existing secrets continue to work without manual intervention

Important

Certificate Management with gMSA: Unlike traditional service accounts where Nodinite can auto-generate and manage certificates, gMSA accounts require you to manually provision and manage certificates in the LocalMachine store. You must provide certificates from your own PKI or certificate authority and handle certificate renewal. This trade-off gives you automatic password rotation while requiring manual certificate lifecycle management.

When to Use gMSA:

  • ✅ Nodinite v7+ environments only - gMSA not supported in v6 or earlier
  • ✅ Have certificate management infrastructure - Internal PKI, cert automation, renewal processes
  • ✅ Multi-server environments - Same gMSA across all servers
  • ✅ Strict password rotation policies - Automatic rotation required
  • ⚠️ Requires Active Directory - Domain environment with Windows Server 2012+ forest level
  • ⚠️ Manual certificate management - You must provision and renew certificates

When to Use Traditional Service Accounts:

  • ✅ Simpler setup - Nodinite auto-generates and manages certificates
  • ✅ No certificate infrastructure needed - Everything managed by Nodinite
  • ✅ v7+ password change support - Can change password without breaking encryption
  • ✅ Nodinite v6 or earlier - gMSA not supported, must use traditional accounts

For step-by-step gMSA setup instructions, see Configure Group Managed Service Accounts (gMSA).

For traditional service account setup, see How to set Logon as a Service right.

sequenceDiagram participant Admin as Administrator participant Service as Service Account participant App as Nodinite Application Admin->>Service: Change password Service->>App: Restart with new password App->>Service: Access certificate store App->>App: Decrypt secrets using existing certificate Note right of App: "No re-entry of secrets required (v7)"

*This diagram illustrates how changing the service account password does not break secret decryption in Nodinite v7 and later.

Important

If you change the service account that runs the Nodinite application, you must MOVE the existing certificate from the old account's personal certificate store to the new account's personal store.
This step is critical because the certificate used for secret encryption and decryption is stored under the personal store of the service account. Without moving the certificate, the new account will not be able to decrypt existing secrets, which may result in application errors or loss of access to sensitive configuration data.

How to move the certificate

💡Required steps when changing a service account.

  1. Export the certificate (including the private key) from the old service account's personal store.
  2. Import the certificate into the new service account's personal store.
  3. Ensure the new account has appropriate permissions to access the certificate.
  4. You must restart the Nodinite services after moving the certificate for changes to take effect.
  5. Remove the certificate from the old account's store if no longer needed.

Next Step

Windows Certificates - You can use the Nodinite Windows Server Monitoring Agent to monitor the certificates used for secret encryption (and any other certificates within Windows).

To go deeper into the broader topic of secure secret handling, encryption, and monitoring: