TeamcenterKnowledge

SSO Setup

Deployment Center over TLS

Deployment Center is a different stack from Active Workspace: Jetty 12.0.16 under C:\apps\DC\webserver, running as DC_Service. So it wants a keystore, not the PEM pair the Node gateway takes.

Result: https://siemensdc:8070/deploymentcenter/. Same port, scheme changed.

It is a swap, and the guide says so

From Deployment Center, Usage 2606, section "HTTPS communication" (1-6/1-7), quoted rather than paraphrased:

  • "Setting it to true enables HTTPS and disables HTTP communication with Deployment Center."
  • "After you enable HTTPS, Deployment Center refuses all HTTP connections."
  • "Deployment Center services and utilities must use HTTPS."

The named utilities are send_configuration_to_dc, deploy and dc_quick_deploy. So enabling this changes how DC is driven, not just how it is browsed.

★★ The trap: the properties field that does nothing

dcserver.properties carries what look like the authoritative settings:

DC_HTTPS_ENABLED=
DC_KEYSTORE_PATH=
DC_KEYSTORE_PASSWORD=
DC_TRUSTSTORE_PATH=
DC_TRUSTSTORE_PASSWORD=
DC_CERTIFICATE_TYPE=

DC_KEYSTORE_PATH and DC_KEYSTORE_PASSWORD are read by no script in the entire DC tree, and installAndRunDCService.bat passes no keystore options to the JVM. Setting them alone has zero effect, while looking completely correct.

What actually takes effect is jetty.sslContext.* in jetty_base/start.d/ssl.ini, which the vendor script creates and leaves entirely commented out.

⇒ Set both. The properties file is what a human reads; the ssl.ini is what Jetty obeys.

DC_HTTPS_ENABLED is read, by createJettyBase.bat and by the repo subscriber and scanner scripts, so it is not inert. Only the keystore pair is.

What was changed

1. Keystores (both PKCS12, in C:\apps\DC\webserver\config):

File Contents
dc-keystore.p12 server cert + private key + CA chain, alias dcserver
dc-truststore.p12 the Xcelerator Local Root CA, alias xcelerator-local-ca

Built from the same certificate as Active Workspace:

openssl pkcs12 -export -in tc-server.crt -inkey tc-server.key \
  -certfile ca.crt -name dcserver -out dc-keystore.p12

★ Use an alphanumeric store password. These values are read by .bat scripts, and a ! in a password can be mangled by batch delayed expansion. The live password is recorded in dcserver.properties on the guest and is deliberately not published here.

2. C:pps\DC\webserver\dcserver.properties (note: NOT under config\): DC_HTTPS_ENABLED=true, plus the keystore, truststore and DC_CERTIFICATE_TYPE=PKCS12 values.

3. The vendor script, which adds the Jetty modules based on that flag:

if /I "%DC_HTTPS_ENABLED%"=="true" (
   java -jar %JETTY_HOME%\start.jar --add-module=ssl,https,ee9-deploy,server
) else (
   java -jar %JETTY_HOME%\start.jar --add-module=http,ee9-deploy,server
)

Running it produced start.d/ssl.ini and start.d/https.ini. Note it only adds: it does not remove http.ini.

4. C:pps\DC\webserver\webserver\jetty_base\start.d\ssl.ini, the part that actually takes effect. ⚠ Note the doubled webserver segment: the single-segment path does not exist, and a reader who guesses it will find nothing.

jetty.ssl.port=8070
jetty.ssl.sniHostCheck=false
jetty.sslContext.keyStorePath=C:/apps/DC/webserver/config/dc-keystore.p12
jetty.sslContext.keyStoreType=PKCS12
jetty.sslContext.trustStorePath=C:/apps/DC/webserver/config/dc-truststore.p12
jetty.sslContext.trustStoreType=PKCS12
# keyStorePassword / keyManagerPassword / trustStorePassword also set

★ sniHostCheck=false is deliberate. This host is legitimately reached as siemensdc, as an IP and as an FQDN. Jetty's SNI check rejects a mismatch with a bare HTTP 400 that reads exactly like an application error, which is a miserable thing to debug.

5. http.ini renamed to http.ini.disabled-2026-08-15, since HTTPS disables HTTP. Renaming rather than deleting keeps it reversible; Jetty only reads *.ini.

6. Restarted DC_Service only.

★★★ Do not restart or force-kill DC_RepoService. Force-killing it orphans a java child that keeps holding tcp://SIEMENSDC:8073, after which every DC service fails to start with an ActiveMQ bind error that looks like a broken service and is not. Restarting DC_Service alone avoids the whole area, and is sufficient because only DC_Service serves 8070.

Verified afterwards

  • GET /deploymentcenter/ returns HTTP 200 from Jetty 12.0.16.
  • GET /deploymentcenter/rest/environments returns 401, which is the REST layer answering correctly over TLS. Auth-required is the right response, not a failure.
  • Plain HTTP on 8070 fails at transport level, as documented.
  • All four DC services Running afterwards.
  • Jetty's own log, rather than just an open port: Started ServerConnector{SSL, (ssl, http/1.1)}{0.0.0.0:8070}.

⚠ Caveat, stated not buried

The guide describes HTTPS as an install or upgrade time setting (useHttpsCommunication in the installation .properties). This was applied to a live install using the same switch the vendor script reads. It works and is verified above, but:

  • it is not the install-time path the guide describes, and
  • DC's repo and publisher services were not re-registered.

If a DC utility or a deploy step misbehaves, suspect this first. No full deployment cycle has been run through it yet.

★★ A truststore that openssl builds and the JVM cannot read

Found 2026-08-15 while issuing a second certificate from this CA, and it is the "succeeds and does nothing" shape in its purest form.

openssl pkcs12 -export -nokeys -in ca.crt -name my-ca -out truststore.p12   # exit 0

That writes a plausible 1.7 KB file. keytool -list against it reports zero entries: a certificate-only PKCS12 produced by openssl is not surfaced by the JVM as a trustedCertEntry. A Java consumer handed that truststore trusts nothing, and says so only as a handshake failure much later.

⇒ Build a truststore with keytool, not openssl, and assert on the entry count:

keytool -importcert -noprompt -alias <ca-alias> -file ca.crt         -keystore truststore.p12 -storetype PKCS12 -storepass <pw>
keytool -list -keystore truststore.p12 -storetype PKCS12 -storepass <pw>
#   want: "Your keystore contains 1 entry" and "trustedCertEntry"

The keystore (cert + private key) is fine from openssl: it holds a PrivateKeyEntry and reads back correctly. It is only the cert-only truststore that is silently empty.