TLS for Bolt/HTTPS, Certificate Trust, Encryption in Transit, and Client Verification

Learning outcomes

A password can authenticate AtlasMart correctly while an attacker on the network still observes or tampers with traffic if transport is not protected. TLS adds confidentiality and peer authentication only when certificate trust and hostname verification are meaningful. “Encrypted” is therefore not the same as “verified.”

1. TLS protects channels, not authorization

Remote Bolt/HTTPS should use trusted TLS. A certificate does not grant graph privileges, and RBAC does not encrypt bytes on the wire; layers complement each other.

2. URI schemes encode routing and trust intent

3. Generate disposable self-signed PEM material

$Root = Join-Path $PWD 'atlasmart-security-lab'$Bolt = Join-Path $Root 'certificates\bolt'$Https = Join-Path $Root 'certificates\https'New-Item -ItemType Directory -Force $Bolt,$Https | Out-Null# Requires Docker, not host OpenSSL.docker run --rm -v "${Bolt}:/work" alpine/openssl req `  -x509 -nodes -newkey rsa:2048 -days 2 `  -keyout /work/private.key -out /work/public.crt `  -subj '/CN=localhost' `  -addext 'subjectAltName=DNS:localhost,IP:127.0.0.1'Copy-Item "$Bolt\private.key" "$Https\private.key"Copy-Item "$Bolt\public.crt" "$Https\public.crt"

The two-day certificate is intentionally disposable and includes SANs for the lab hostnames. Production certificates should be CA-issued, tracked, rotated before expiry and protected by filesystem/secret-store controls.

4. Start an isolated TLS-required Community container

docker rm -f atlasmart-neo4j-secure 2>$null$Root = (Resolve-Path .\atlasmart-security-lab).Pathdocker run -d --name atlasmart-neo4j-secure `  -p 127.0.0.1:17473:7473 `  -p 127.0.0.1:17687:7687 `  -e NEO4J_AUTH=neo4j/atlasmart-secure-lab-2026 `  -e NEO4J_server_http_enabled=false `  -e NEO4J_server_https_enabled=true `  -e NEO4J_server_bolt_tls__level=REQUIRED `  -e NEO4J_dbms_ssl_policy_bolt_enabled=true `  -e NEO4J_dbms_ssl_policy_bolt_base__directory=/ssl/bolt `  -e NEO4J_dbms_ssl_policy_https_enabled=true `  -e NEO4J_dbms_ssl_policy_https_base__directory=/ssl/https `  -v "${Root}\certificates:/ssl:ro" `  neo4j:2026.07.1docker logs --tail 120 atlasmart-neo4j-secure

If your host/container path handling differs, use the same Neo4j settings in neo4j.conf. The important mechanism is separate enabled SSL policies plus server.bolt.tls_level=REQUIRED, not this exact Docker invocation.

5. Prove encrypted success and plain failure

# Inspect certificate presented by Bolt.docker run --rm --network host alpine/openssl s_client `  -connect 127.0.0.1:17687 -servername localhost# Self-signed lab scheme: encrypted but CA verification relaxed.cypher-shell -a bolt+ssc://localhost:17687 `  -u neo4j -p atlasmart-secure-lab-2026 "RETURN 1 AS tls_ok;"# Expected to fail because server requires TLS.cypher-shell -a bolt://localhost:17687 `  -u neo4j -p atlasmart-secure-lab-2026 "RETURN 1;"

For production, replace the self-signed certificate with a CA-issued certificate and use bolt+s or neo4j+s. Also test that connecting with the wrong hostname fails verification.

6. HTTPS and certificate verification

# -k is deliberately allowed ONLY for this isolated self-signed test.curl.exe -k https://localhost:17473/# Production check: omit -k and provide a trust chain trusted by the client.# curl.exe https://db.example.com:7473/

Neo4j documentation recommends disabling unencrypted HTTP when HTTPS is enabled. Test redirect/connector expectations explicitly; enabling HTTPS does not automatically make every client use it.

7. Private-key and certificate lifecycle

8. Cleanup

docker rm -f atlasmart-neo4j-secureRemove-Item -Recurse -Force .\atlasmart-security-lab

Production judgment

Summary and next step

Transport security is a verified identity channel, not an “encryption checkbox.” Lesson 4 moves the same lifecycle discipline to credentials themselves: creation, delivery, rotation, evidence, revocation and incident response.

Authoritative references

• Current Neo4j versions — Current server and 5.26 LTS release snapshot.
• Security checklist — Official baseline for deployment, transport, extensions, backup and filesystem security.
• Manage users — Native users, password handling, Community/Enterprise user-model distinctions.
• Role-based access control — Enterprise RBAC model and GRANT/DENY/REVOKE semantics.
• Read privileges — TRAVERSE, READ and MATCH graph privilege semantics.
• Write privileges — CREATE, DELETE, SET, MERGE and WRITE privilege semantics.
• SSL framework — Bolt/HTTPS TLS policies, certificate files, TLS levels and URI schemes.
• Procedure/function privileges — Execute and boosted-execution privilege boundaries.
• Python driver advanced connections — TLS/trust and rotating authentication token support in the maintained Python driver.
• Configure network connectors — Connector exposure and TLS-related network configuration.
• Neo4j Python driver connectivity — Driver URI/auth basics and secure Aura scheme guidance.