This community thread discusses Encrypting SQL Server Connections in web.config — a topic related to setting up and configuring APG vNext on your server.
Overview
Getting APG vNext running correctly requires proper IIS configuration, a SQL Server database, and correct settings in your web.config file. Common setup issues are typically related to one of these areas.
Common Configuration Checklist
- IIS Application Pool: Set to .NET 4.0 Integrated Pipeline. APG vNext is not compatible with Classic mode.
- Database Connection String: Verify the server name, database name, username, and password in
web.config. - File Permissions: The IIS app pool identity must have read/write access to the
upfilesfolder. - URL Rewriting: Install the IIS URL Rewrite module for SEO-friendly URLs.
- Full-Text Search: Enable Full-Text Indexing in SQL Server for the search feature to work.
Get Help
If you are experiencing an issue not covered here, post in the support forum with your error message and server configuration details. See also: Installation Guide | FAQ
Encrypting SQL Server Connections in APG vNext web.config
By default, SQL Server connections in APG vNext send data in plaintext over the network. For production deployments - especially where the database server is on a different machine from the web server - encrypting the connection prevents credentials and forum data from being intercepted. This guide covers enabling TLS encryption for the SQL Server connection and optionally protecting the connection string from being read in web.config.
Enabling Connection Encryption
<!-- Add Encrypt=True to the connection string -->
<connectionStrings>
<add name="APGConnection"
connectionString="Server=sql.yourserver.com;Database=ForumDB;
User Id=apguser;Password=yourpassword;
Encrypt=True;TrustServerCertificate=False;
Connection Timeout=30;"
providerName="System.Data.SqlClient" />
</connectionStrings>Note: Set TrustServerCertificate=False for production. Only use True during development when the SQL Server uses a self-signed certificate.
Encrypting the Connection String in web.config
# Encrypt the connectionStrings section using aspnet_regiis:
cd C:\Windows\Microsoft.NET\Framework64 4.0.30319
aspnet_regiis -pe "connectionStrings" -app "/YourForumApp"
# The section is now encrypted and unreadable in plain text
# APG vNext decrypts it automatically at runtimeAlways-Encrypted Columns (SQL Server 2016+)
For the highest level of protection - encrypting sensitive member data (email, IP addresses) at the column level so even database administrators cannot read it:
-- Enable Always Encrypted on email column:
ALTER TABLE apg_Members
ALTER COLUMN Email NVARCHAR(256)
ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY=MemberEmailKey,
ENCRYPTION_TYPE=Deterministic,
ALGORITHM='AEAD_AES_256_CBC_HMAC_SHA_256');SQL Server TLS Certificate Requirements
Enabling Encrypt=True in the connection string requires the SQL Server to have a valid TLS certificate installed. In production, this should be a certificate from a trusted Certificate Authority (CA) that your web server trusts. For development environments, a self-signed certificate is acceptable if TrustServerCertificate=True is also set (never use this setting in production). In SQL Server 2019 and later, the SQL Server Configuration Manager provides a built-in interface for installing and managing the SQL Server TLS certificate. For SQL Server 2016 and 2017, the certificate must be installed in the Windows Certificate Store on the SQL Server machine and assigned to the SQL Server service account before it becomes available in the SQL Server Configuration Manager.
Encrypted Connections in Load-Balanced Environments
When APG vNext runs behind a load balancer with multiple application servers connecting to a shared SQL Server, ensure all application servers have the SQL Server's CA certificate in their Trusted Root Certification Authorities store. If any application server is missing the trusted certificate, its connections will fail when Encrypt=True and TrustServerCertificate=False are set — even if other servers connect successfully. Document the certificate trust configuration as part of your server provisioning runbook so that new application servers added to the cluster are automatically configured with the required SQL Server certificate trust.
Auditing Connection Encryption
Verify that all connections to SQL Server are using encryption by querying the SQL Server DMV that tracks connection encryption status:
-- Check whether active connections are encrypted:
SELECT s.session_id,
c.client_net_address,
c.encrypt_option,
s.program_name
FROM sys.dm_exec_connections c
JOIN sys.dm_exec_sessions s ON s.session_id = c.session_id
WHERE s.program_name LIKE '%APG%';
-- encrypt_option should be TRUE for all APG vNext connections
-- Any session showing FALSE is connecting without encryptionConnection String Security in Multi-Server Deployments
In multi-server APG vNext deployments where multiple web servers share a single SQL Server database, the connection string (including credentials) is present in the web.config of every web server. This increases the attack surface: a compromise of any single web server exposes the database credentials. Mitigate this risk through several measures: use a dedicated SQL Server login for APG vNext with the minimum required permissions (SELECT, INSERT, UPDATE, DELETE, EXECUTE on APG vNext objects only — never sysadmin or db_owner), rotate the database password quarterly and update web.config on all servers simultaneously, and always encrypt the connectionStrings section on all servers using aspnet_regiis so the password is not in plaintext even if a web.config backup is inadvertently exposed.
Credential Management Best Practices
Never hardcode database passwords in source control. Store them in encrypted web.config sections only, and document the rotation procedure in your runbook.
Related Resources
Looking for more help? Browse the support forum or check the Knowledge Base.