Securing Teamcenter Active Workspace: How to Configure HTTPS | CTGT Innovations

Teamcenter PLM · Pillar 1 — Practitioner Insights

Securing Teamcenter Active Workspace: A Complete Guide to Configuring HTTPS

Everything a Teamcenter administrator needs to enable SSL/TLS on Active Workspace — from certificate generation to Java keystore import, with coverage for both CA-signed and self-signed certificates.

Security & Infrastructure

Level: Intermediate–Advanced

Published by CTGT Innovations Inc. · April 2026

Contents

Why HTTPS Matters for AW
·
HTTP vs HTTPS: What Changes
·
Prerequisites
·
Step-by-Step Configuration
·
Self-Signed Certificate Handling
·
Verification & Testing
·
Key Takeaways

Why HTTPS Is No Longer Optional for Active Workspace

Active Workspace (AW) has evolved into the primary Teamcenter client for most organisations. Unlike the legacy Rich Client, AW is browser-based and increasingly accessed from outside the corporate network — from home offices, supplier sites, and mobile devices — without a VPN. That accessibility is a major operational benefit. It is also a security exposure if the communication channel is left unencrypted.

Configuring Teamcenter Active Workspace with HTTPS is not a nice-to-have hardening step. For any environment where AW is internet-facing or carries design IP, regulatory data, or supplier information, it is a baseline requirement. In TISAX-certified and aerospace-regulated environments, it is a compliance obligation.

This article explains exactly what HTTPS does in the context of Teamcenter Active Workspace, when to use a CA-signed certificate versus a self-signed certificate, and how to complete the full configuration — including the step that is most commonly missed: importing the certificate into the Java keystore on client machines.

What HTTPS Protects Against

Standard HTTP transmits all data — including login credentials, session tokens, design metadata, and file content — as plain text. Any network intermediary (a proxy, a misconfigured switch, a malicious actor on the same network segment) can read and record that traffic. HTTPS addresses this through three mechanisms:

Encryption: All data in transit is encrypted using TLS, making interception meaningless without the private key.
Authentication: The SSL certificate proves to the client browser that it is genuinely communicating with the intended server — not an impersonator.
Integrity: TLS includes mechanisms to detect whether data has been tampered with in transit.

For Teamcenter specifically, this matters because AW sessions carry product structure data, CAD file transfers, workflow task completions, and user credential exchanges — all of which are high-value targets in a manufacturing IP context.

HTTP vs HTTPS in Active Workspace: What Actually Changes

The most visible signal of HTTPS is the padlock icon in the browser address bar and the https:// prefix on the URL. But the underlying change is in how the Active Workspace gateway service handles incoming connections.

Active Workspace accessed over HTTP — browser showing Not secure warning — Screenshot: Active Workspace accessed over HTTP — browser showing "Not secure" warning in the address bar (Chrome or Edge).

Screenshot: Active Workspace accessed over HTTPS — browser showing padlock icon and https:// prefix confirmed secure in address bar.

The gateway configuration file (config.json) is where the switch happens. Adding the certFile and keyFile paths to the gateway configuration instructs the gateway process to terminate TLS connections using the provided certificate. From that point, the gateway listens on the HTTPS port and all client-server communication is encrypted.

No changes are required to pool server configuration, the Teamcenter application tier, or the database tier. HTTPS terminates at the gateway — the internal communication stack between gateway and pool servers is unchanged by this configuration.

Prerequisites Before You Begin

Before starting the configuration, confirm the following are in place:

Active Workspace is installed and accessible over HTTP — verify a working HTTP login before switching to HTTPS.
You have administrator access to the server hosting the AW gateway process.
You have identified the correct gateway version folder. The folder name changes across AW releases (e.g., gateway-1.5.0, gateway-2.x.x) — confirm the version installed on your server.
OpenSSL is available on the server (required for self-signed certificate generation). For production environments, a signed certificate and key file from your organisation's Certificate Authority (CA) should be available.
The Java Development Kit (JDK) bundled with your AW installation is accessible — needed for the keytool command used in self-signed certificate deployments.
A change window has been scheduled — restarting the Process Manager will interrupt active AW sessions.

CA-Signed vs Self-Signed Certificates

For production environments, always use a certificate signed by a trusted Certificate Authority — either your organisation's internal CA or a public CA. CA-signed certificates are automatically trusted by browsers without any additional client-side configuration.

Self-signed certificates are appropriate for development, test, and local environments only. They provide the same encryption as CA-signed certificates but will trigger browser security warnings and require manual trust installation on every client machine — an operational overhead that makes them unsuitable for production use.

Note: If you are setting up HTTPS in a production environment, request the .crt (certificate) and .key (private key) files from your IT security or infrastructure team before proceeding. Do not generate self-signed certificates for production use.

Step-by-Step HTTPS Configuration

The following steps cover the full configuration sequence. Steps 1 and 2 are for self-signed certificate generation only. If you have CA-provided certificate and key files, start at Step 3.

Generate the Private Key and Certificate Signing Request (CSR)

Self-signed only

Run the following OpenSSL command on the server to generate a 2048-bit RSA private key and a Certificate Signing Request simultaneously. Replace CTGTNB00028 with a filename relevant to your environment.

openssl req -newkey rsa:2048 -nodes -keyout CTGTNB00028.key -out CTGTNB00028.csr

What each parameter does:

-newkey rsa:2048 — generates a new RSA key pair using 2048-bit key length.
-nodes — the private key will not be passphrase-protected. Required for automated server startup; a passphrase would require manual entry each time the gateway restarts.
-keyout <filename>.key — writes the private key to this file. Keep this file secure — it must not be shared.
-out <filename>.csr — writes the CSR to this file. The CSR contains your server's public key and identity information.

You will be prompted to enter details including country, organisation name, and the Common Name (CN). The CN must match the hostname users will use to access Active Workspace (e.g. aw.company.com). A CN mismatch will cause certificate validation errors in browsers.

Generate the Self-Signed Certificate from the CSR

Self-signed only

Use OpenSSL to sign the CSR with the private key and produce the certificate file (.crt):

openssl x509 -signkey CTGTNB00028.key -in CTGTNB00028.csr -req -days 365 -out CTGTNB00028.crt

Parameter notes:

x509 — specifies X.509 certificate format, the standard for TLS certificates.
-signkey — the private key used to self-sign the certificate.
-days 365 — sets the certificate validity to 365 days. Calendar a renewal before expiry — expired certificates will cause all users to receive browser security errors.
-out <filename>.crt — the output certificate file.

At this point you should have two files: <name>.crt (certificate) and <name>.key (private key). These are the two files referenced in the gateway configuration.

Update the Gateway config.json

Required for all environments

Locate the gateway configuration file at the path below. The folder name will reflect your AW version:

# Path pattern — adjust for your AW version
%TC_ROOT%\microservices\gateway-[version]\config.json

config.json open in text editor showing certFile and keyFile properties — Screenshot: config.json file open in a text editor, showing the HTTPS-related certificate and key entries added — highlight the certFile and keyFile properties with their file paths.

Add or update the following properties in the config.json to reference your certificate and key files. Provide the full absolute path to each file:

{
  "httpsPort": 443,
  "certFile": "C:\\certs\\CTGTNB00028.crt",
  "keyFile":  "C:\\certs\\CTGTNB00028.key"
}

Ensure the certificate and key files are stored in a location that the gateway service account has read access to. Storing them under %TC_ROOT% is common practice, but a dedicated secure certificate directory is preferable from a security governance standpoint.

Important: The gateway folder name changes between AW versions. Always confirm the correct folder for your installation before editing config.json. Editing the wrong version folder will have no effect.

Restart the Process Manager

Required for all environments

Changes to config.json take effect only after the Process Manager service is restarted. On Windows, open the Services console (services.msc), locate the Teamcenter Process Manager service, and restart it.

This will briefly interrupt all active AW sessions. Communicate the expected downtime window to users before proceeding in production environments.

After the restart, open a browser and navigate to your AW URL with the https:// prefix. If the configuration is correct, you will see the padlock icon and the login page will load over HTTPS.

Handling Self-Signed Certificates on Client Machines

When using a self-signed certificate, browsers will display a security warning because the certificate is not signed by a trusted CA. In a controlled environment (test server, developer workstation), this can be resolved by importing the certificate into the Java keystore on each client machine. This step is not required when using a CA-signed certificate.

Step 5: Export the Certificate from the Browser

After navigating to the HTTPS URL, the browser will display a "Not Secure" warning. Click the warning icon in the address bar to access the certificate details and export the .crt file to a local path on the client machine.

Browser certificate details panel open with export certificate option highlighted — Screenshot: Browser address bar showing "Not secure" warning clicked — certificate details panel open with the export/download certificate option highlighted.

Step 6: Import the Certificate into the Java Keystore

Run the following keytool command on the client machine, adjusting paths for your environment. The cacerts keystore is the trust store used by the JDK bundled with Active Workspace:

keytool -importcert ^
  -alias CTGTNB00028 ^
  -file C:\Temp\CTGTNB00028.crt ^
  -trustcacerts ^
  -keystore C:\AWC\jdk\jdk11.0.18\lib\security\cacerts ^
  -storetype JKS

Parameter reference:

Parameter	Purpose	Notes
`-alias`	Label for this certificate entry in the keystore	Use a descriptive name — the hostname is a good choice
`-file`	Path to the exported `.crt` file on the client	Adjust to wherever you saved the exported certificate
`-trustcacerts`	Instructs keytool to check against existing CA certificates in the keystore	Required when adding self-signed certs
`-keystore`	Path to the Java cacerts keystore	Path varies by JDK version — adjust to match your AW JDK path
`-storetype JKS`	Declares the keystore format as Java KeyStore	JKS is standard for JDK versions prior to JDK 9; newer versions may use PKCS12

When prompted for the keystore password, the default Java cacerts password is changeit. If your organisation has changed this default, use the current password.

This keytool step must be repeated on every machine from which users will access the self-signed AW instance. In environments with many workstations, consider distributing the certificate via Group Policy rather than running keytool manually.

JDK path note: The path to cacerts depends on the JDK version bundled with your AW installation. Inspect the AW installation directory to identify the correct JDK folder before running the command.

Verification and Troubleshooting

After completing the configuration steps, perform the following checks to confirm HTTPS is functioning correctly:

Basic Verification Checklist

Navigate to the AW URL with https:// prefix — the login page should load without certificate errors.
Confirm the padlock icon is visible in the browser address bar and clicking it shows the certificate as valid.
Log in and perform a basic object search to confirm the application is functional over HTTPS, not just loading the login page.
Verify the HTTP URL (http://) either returns a redirect to HTTPS or is no longer accessible — leaving HTTP active alongside HTTPS allows users to bypass the encrypted channel.

Common Issues

Symptom	Likely Cause	Resolution
Browser shows "NET::ERR_CERT_COMMON_NAME_INVALID"	Certificate CN does not match the hostname	Regenerate certificate with the correct CN matching the AW URL
HTTPS URL does not load at all	config.json edit not saved, or wrong gateway folder edited	Confirm gateway version folder, re-check config.json, restart Process Manager
Browser warning persists after keytool import	Browser uses its own trust store, not the Java keystore	Also install certificate in Windows Certificate Store or browser trust store
Certificate expired warning	Self-signed certificate has passed its validity date	Regenerate certificate and repeat configuration; set a renewal reminder
HTTP still accessible after HTTPS configured	HTTP port not disabled in gateway config	Disable the HTTP port in config.json or block it at the firewall level

Key Takeaways

HTTPS is a baseline requirement for any AW environment accessed outside the corporate network. Encrypting the channel protects credentials, session tokens, and design IP from interception.
The gateway config.json is the single point of change — adding certFile and keyFile paths is all that is required at the server level. No changes are needed to the Teamcenter application tier or database.
Use CA-signed certificates in production. Self-signed certificates require per-machine keytool import and will cause browser warnings — acceptable for dev/test, not for production rollout.
The CN in the certificate must exactly match the AW hostname. A mismatch causes browser validation failures that cannot be dismissed in modern browsers without a security exception.
Plan for certificate renewal. Self-signed certificates with a 365-day validity will expire. Calendar the renewal date at the time of generation and build a renewal process into your AW operational runbook.
Disable HTTP after enabling HTTPS. Leaving both protocols active allows users to bypass encryption. Block the HTTP port at the firewall or disable it in the gateway configuration once HTTPS is confirmed working.

About CTGT Innovations Inc.

CTGT Innovations Inc. is a specialist PLM implementation firm with deep Teamcenter expertise across automotive, aerospace, and industrial manufacturing. With consultants spanning 5 to 30+ years of hands-on Teamcenter experience, CTGT delivers advisory, implementation, integration, migration, and managed services across the full Siemens Xcelerator portfolio. Headquartered in Pune, Toronto, and Munich. Visit www.ctgti.com for more.

Siemens Elite Partner TISAX Certified ISO 9001 Certified