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 and in the Configuration Database (for example, Alarm Plugin passwords). 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 or database 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.
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
Understanding the Certificate Architecture
You choose the Secret Management settings when you register the environment in the Nodinite Portal, in the Secret Management section of Step 2: Auth. The CLI (Step 7) writes them into the generated installation. Each service then loads, or generates, its encryption certificate from the Windows Certificate Store of the account it runs as, and uses it to encrypt and decrypt secrets. Monitoring Agents have the same settings on the Secret Management tab of their Remote Configuration Settings tab.
Certificate lifecycle: startup checks (blue), automated certificate handling and encryption (green), and the expiry watch (yellow) that triggers renewal. Configure it in the Portal Auth step, and watch expiry with the Windows Server Monitoring Agent (Windows Certificates).
Why Certificate-Based Encryption?
Nodinite uses a hybrid encryption approach that combines:
- Symmetric encryption (AES-256) - Fast encryption for your actual secrets
- 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
- ✅ Automated lifecycle - Certificates renew automatically before expiration
- ✅ Platform integration - Uses the operating system's built-in certificate store
Certificate Store Locations
Where the certificate lives depends on the type of service account:
| Service account type | Certificate store | Who creates the certificate | Learn more |
|---|---|---|---|
| Traditional (named) service account | Personal store of the account (Cert:\CurrentUser\My) |
Nodinite auto-generates and renews it | Logon as a Service right |
| Group Managed Service Account (gMSA) | Cert:\LocalMachine\My, private key readable by the gMSA |
You provision and renew it from your own PKI | Install Certificates for gMSA |
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 or the Configuration Database
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
Encryption and decryption: the certificate stays in the service account's Windows Certificate Store, and only the encrypted value is written to the configuration file or the Configuration Database.
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. In the Portal Auth step, the automatic option is shown as Auto-generate certificate (recommended).
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
Understanding the Difference: v7 vs v6
| Aspect | Nodinite v6 and earlier | Nodinite v7 |
|---|---|---|
| Changing the service account password | ❌ Encryption broke immediately; all encrypted secrets became inaccessible | ✅ Secrets keep working; restart the service with the new password |
| Re-entering secrets | ❌ Every password and connection string had to be re-entered | ✅ No re-entry needed |
| Downtime and risk | ❌ Extensive testing and reconfiguration; easy to miss a secret | ✅ Zero downtime; rotate passwords regularly without fear |
| gMSA support | ❌ Not supported | ✅ Supported |
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.
Changing the service account password does not break secret decryption in Nodinite v7, because the certificate stays in the account's store (Logon as a Service right).
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. You set the account in the Portal Auth step; a gMSA name ends with $.
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 is certificate handling:
- ✅ 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 in the LocalMachine store. You need your own PKI or certificate authority to issue and renew certificates; see Install Certificates for gMSA.
Should You Use gMSA?
| Use gMSA if | Use traditional service accounts if |
|---|---|
| ✅ You have an internal PKI or certificate management infrastructure | ✅ You want Nodinite to auto-generate and manage certificates (simpler setup) |
| ✅ You have Active Directory (Windows Server 2012+ forest level) | ✅ You don't have certificate management infrastructure |
| ✅ Your security policy requires automatic password rotation | ✅ You prefer simplicity over automatic password rotation |
| ✅ You run multi-server environments |
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.
Important: Changing the Service Account Itself
Changing the password is different from changing the service account:
- ✅ Changing password - 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:
- Export the certificate (including the private key) from the old service account's personal store.
- Import the certificate into the new service account's personal store.
- Ensure the new account has appropriate permissions to access the certificate.
- You must restart the Nodinite services after moving the certificate for changes to take effect.
- Remove the certificate from the old account's store if no longer needed.
When the new account is a gMSA, import the certificate into Cert:\LocalMachine\My instead and grant the gMSA read access to the private key; Migration from Traditional Account has the PowerShell for each step.
Next Steps
- Step 2: Auth › Secret Management
- Windows Certificates - Use the Nodinite Windows Server Monitoring Agent to monitor the certificates used for secret encryption (and any other certificates within Windows)
- Configure Group Managed Service Accounts (gMSA)
Related Topics
- Install Certificates for gMSA
- Migration from Traditional Account
- Key Management, Backup & Data Residency Policy
- Logon as a Service right
- How do I configure a Monitoring Agent?
- Troubleshooting Overview
- Review Best Practices for Application-Level Secret Management
- Learn about Certificate Lifecycle Automation
- Explore How Hybrid Encryption Works
- SQL Server Connection Strings