VISUAL_ENCRYPT=yes once vsql has a trusted certificate #5

New Issue

2026-10-19T02:50:12Z

spencerm commented

2026-10-19 02:50:12 +00:00

The VisualKit connection runs with Encrypt=no because vsql has no certificate the container trusts.

To answer: whether IT will issue vsql a certificate from PESCO-PSYLOCKE-CA (now SHA-256) so the production stack can run with VISUAL_ENCRYPT=yes, and when.

Plan reference: Q6 in docs/PLAN.md (open questions). Answer here; the build takes the default until then.

The VisualKit connection runs with Encrypt=no because vsql has no certificate the container trusts. **To answer:** whether IT will issue vsql a certificate from PESCO-PSYLOCKE-CA (now SHA-256) so the production stack can run with VISUAL_ENCRYPT=yes, and when. --- Plan reference: Q6 in [docs/PLAN.md](https://gt.pescoinc.biz/spencerm/PacketStation/src/branch/main/docs/PLAN.md) (open questions). Answer here; the build takes the default until then.

spencerm added the production decision: IT labels 2026-10-19 02:50:12 +00:00

spencerm commented

2026-10-19 03:12:23 +00:00

Checked from the test stack image on docker-1 on 2026-10-18 against vsql.pesco.com\DEV:

VISUAL_ENCRYPT=trust (encrypt, do not verify): connects. So the instance does serve TLS.
VISUAL_ENCRYPT=yes (encrypt and verify): fails with OpenSSL certificate verify failed: EE certificate key too weak, with the system trust store and also with the PESCO CA bundle as the trust file. The server certificate's RSA key is below 2048 bits, which Debian 12 OpenSSL refuses at its default security level. That matches SQL Server's auto-generated self-signed certificate rather than a CA-issued one.

What IT needs to do before VISUAL_ENCRYPT=yes can be used:

Issue vsql a server certificate from PESCO-PSYLOCKE-CA (now SHA-256): RSA 2048 or better, Server Authentication EKU, subject alternative names vsql.pesco.com and vsql, private key exportable to the SQL Server service account.
Install it in SQL Server Configuration Manager under the protocols of both the DEV and the production instance, and restart each instance (a short VISUAL outage, so off-hours).
Tell Packet Station. The image then gets the PESCO CA added to its OpenSSL trust store at start (the entrypoint can build a combined bundle in /tmp and export SSL_CERT_FILE), and the stacks switch to VISUAL_ENCRYPT=yes.

Until then the stacks run VISUAL_ENCRYPT=no, as VisualKit's own default and docs say (LAN only by decision).

Checked from the test stack image on docker-1 on 2026-10-18 against `vsql.pesco.com\DEV`: - `VISUAL_ENCRYPT=trust` (encrypt, do not verify): connects. So the instance does serve TLS. - `VISUAL_ENCRYPT=yes` (encrypt and verify): fails with OpenSSL `certificate verify failed: EE certificate key too weak`, with the system trust store and also with the PESCO CA bundle as the trust file. The server certificate's RSA key is below 2048 bits, which Debian 12 OpenSSL refuses at its default security level. That matches SQL Server's auto-generated self-signed certificate rather than a CA-issued one. **What IT needs to do before `VISUAL_ENCRYPT=yes` can be used:** 1. Issue vsql a server certificate from PESCO-PSYLOCKE-CA (now SHA-256): RSA 2048 or better, Server Authentication EKU, subject alternative names `vsql.pesco.com` and `vsql`, private key exportable to the SQL Server service account. 2. Install it in SQL Server Configuration Manager under the protocols of both the DEV and the production instance, and restart each instance (a short VISUAL outage, so off-hours). 3. Tell Packet Station. The image then gets the PESCO CA added to its OpenSSL trust store at start (the entrypoint can build a combined bundle in /tmp and export `SSL_CERT_FILE`), and the stacks switch to `VISUAL_ENCRYPT=yes`. Until then the stacks run `VISUAL_ENCRYPT=no`, as VisualKit's own default and docs say (LAN only by decision).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spencerm/PacketStation#5