- 0 minutes to read

Secret Management with Automatic Certificate Handling

New 7.x

What is Secret Management?

Nodinite stores sensitive information like database passwords, API keys, and connection strings in configuration files. These secrets need protection to prevent unauthorized access. Without proper secret management, your passwords would be stored as plain text - readable by anyone with file access.

The Challenge:

  • Configuration files contain sensitive credentials (database passwords, service account passwords, API keys)
  • These files are stored on disk and backed up to multiple locations
  • Plain text passwords create security vulnerabilities and compliance risks
  • Manual certificate management is error-prone and time-consuming
  • Changing service account passwords historically broke encrypted configurations

The Solution:

Nodinite v7 introduces automated secret management using certificate-based encryption. Your secrets are encrypted and can only be decrypted by the authorized service account. The system automatically handles certificate generation, renewal, and lifecycle management - no manual certificate provisioning required.

Why Certificate-Based Encryption?

Nodinite uses a hybrid encryption approach that combines:

  1. Symmetric encryption (AES-256) - Fast encryption for your actual secrets
  2. Asymmetric encryption (RSA) - Secure protection of the encryption keys

This industry-standard approach means:

  • ✅ Strong security - Your secrets are protected with modern cryptography
  • ✅ Zero manual work - Certificates are automatically generated and renewed
  • ✅ Service account flexibility - Change passwords without breaking encryption (v7+)
  • ✅ Automated lifecycle - Certificates renew automatically before expiration
  • ✅ Platform integration - Uses the operating system's built-in certificate store

Quick Overview

On this page, you will learn how to:

  • ✅ 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.

How It Works: Step-by-Step

When you enter a password or connection string in Nodinite, here's what happens behind the scenes:

1. First Time Setup (Automatic):

  • Nodinite checks if an encryption certificate exists
  • If not found, it automatically generates a new certificate
  • The certificate is stored in the Windows Certificate Store under the service account

2. Encrypting Secrets:

  • You enter a password in the Nodinite Web Client
  • The application retrieves the encryption certificate
  • Your secret is encrypted using AES-256
  • The encrypted value is stored in the configuration file

3. Decrypting Secrets:

  • Nodinite needs to connect to a database
  • It retrieves the certificate from the Windows Certificate Store
  • The encrypted password is decrypted
  • The application uses the plain text password to connect

4. Automatic Renewal:

  • Nodinite monitors certificate expiration dates
  • When approaching expiration (default: 30 days before), a new certificate is generated
  • Secrets are re-encrypted with the new certificate
  • Old certificate is retired
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 encryption and decryption process using certificates stored in the operating system's certificate store.

Configuration: Customize Encryption Settings

Most users can rely on the default settings - Nodinite will automatically generate certificates and manage their lifecycle. However, you can customize these settings if your security policies require specific certificate configurations or expiration periods.

When to customize:

  • ✅ Your organization requires specific certificate key sizes (e.g., 4096-bit)
  • ✅ You need custom certificate validity periods for compliance
  • ✅ You want to adjust renewal warning thresholds
  • ⚠️ For most users, the defaults work perfectly - only change if you have specific requirements

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

Service Account Password Changes: What You Need to Know

The Old Problem (Nodinite v6 and earlier)

In older versions of Nodinite, changing a service account password was a nightmare:

  • ❌ Encryption broke immediately - All encrypted secrets became inaccessible
  • ❌ Manual re-entry required - You had to re-enter every password and connection string
  • ❌ High risk of errors - Easy to miss secrets, causing application failures
  • ❌ Service downtime - Required extensive testing and reconfiguration

This made password rotation (a security best practice) extremely difficult and risky.

The New Solution (Nodinite v7)

Nodinite v7 solves this problem completely:

  • ✅ Change passwords freely - Service account password changes don't break encryption
  • ✅ No re-entry needed - All existing secrets continue to work
  • ✅ Zero downtime - Just restart the service with the new password
  • ✅ Security best practices - Now you can rotate passwords regularly without fear

How it works: The encryption certificate is stored separately from the service account password. Changing the password doesn't affect the certificate, so encrypted secrets remain accessible.

For details on service account configuration, 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 get this critical improvement.

Ultimate Password Security: Group Managed Service Accounts (gMSA)

Want to eliminate password management entirely? Nodinite v7 supports Group Managed Service Accounts (gMSA) - Windows automatically rotates the password 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.

What is gMSA?

A Group Managed Service Account is a special type of Windows service account where:

  • Windows rotates the password automatically - Every 30 days, no manual action needed
  • Password is never exposed - Administrators never see or know the password
  • Multiple servers supported - Same gMSA can run services across multiple machines
  • Active Directory managed - Centralized control and auditing

The Trade-off:

  • ✅ Automatic password rotation - Never manually change passwords again
  • ✅ Enhanced security - 30-day rotation without service interruption
  • ⚠️ Manual certificate management - You must provision and renew certificates yourself

Unlike traditional service accounts where Nodinite auto-generates certificates, gMSA accounts require you to manage certificates manually. You need your own PKI or certificate authority to issue and renew certificates.

Should you use gMSA?

Use gMSA if:

  • ✅ You have Nodinite v7 or later
  • ✅ You have an internal PKI or certificate management infrastructure
  • ✅ You have Active Directory (Windows Server 2012+ forest level)
  • ✅ Your security policy requires automatic password rotation
  • ✅ You run multi-server environments

Use traditional service accounts if:

  • ✅ You want Nodinite to auto-generate and manage certificates (simpler setup)
  • ✅ You don't have certificate management infrastructure
  • ✅ You have Nodinite v6 or earlier (gMSA not supported)
  • ✅ You prefer simplicity over automatic password rotation

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: Changing the Service Account Itself

Changing the password is different from changing the service account:

  • ✅ Changing password (v7+) - Same account, new password → Everything works automatically
  • ⚠️ Changing service account - Different account → You must move the certificate

If you switch from one service account to another (e.g., from DOMAIN\ServiceAccount1 to DOMAIN\ServiceAccount2), the certificate must be moved because certificates are stored under each account's personal certificate store.

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: