Certificate Installation for HTTPS Communication

Installing the certificate is a required commissioning step for any client that communicates with the solution over HTTPS (for example a .NET-based order management or PLC integration).

Which case applies to you? The instructions below cover the standard installation, which is served with a self-signed certificate. If the server uses a certificate issued by your organisation's own certificate authority — as is the case at Goodyear — the installation is usually unnecessary. See Sites With a Corporate Certificate Authority.

The solution is served over HTTPS using a self-signed certificate. Until the client machine trusts this certificate, every HTTPS request is rejected before any data is exchanged. This is independent of the specific request being made — it is not caused by submitting an order, it is a prerequisite for establishing the secure connection at all.

Why It Is Needed

A client only accepts an HTTPS connection when it can verify the server's certificate against a trusted authority. Because the certificate is self-signed, it must be added manually to the client machine's trusted root store during commissioning. If this step is skipped, connections fail with a message such as:

The underlying connection was closed:
Could not establish trust relationship for the SSL/TLS secure channel.

Downloading the Certificate

Download the public certificate on the client machine:

• Web interface: Options > Download Certificate in the top navigation bar.
• API endpoint: GET /api/download-cert

The downloaded file is named palletizing_root_cert.crt.

Verify the Downloaded File

Before installing, confirm the file is a real certificate and not an HTML error page:

certutil -dump "C:\path\palletizing_root_cert.crt"

This should print the certificate details (issuer, validity period, SAN). If it errors or you see HTML text, re-download the file via Options > Download Certificate.

Installing the Certificate on Windows

The certificate must be placed in the Local Machine → Trusted Root Certification Authorities store. Use Local Machine (not Current User), because clients that run as a Windows service under a system account read from the machine store.

If double-clicking the .crt file does not offer an Install Certificate… button (e.g. the file opens in a text editor because of a wrong file association), import it directly using one of the following, run as Administrator:

PowerShell

Import-Certificate -FilePath "C:\path\palletizing_root_cert.crt" -CertStoreLocation Cert:\LocalMachine\Root

certutil

certutil -addstore -f "Root" "C:\path\palletizing_root_cert.crt"

MMC snap-in

1. Run certlm.msc (opens the Local Machine certificate store directly).
2. Navigate to Trusted Root Certification Authorities → Certificates.
3. Right-click → All Tasks → Import… and follow the wizard.

After importing, restart the client application or service.

Sites With a Corporate Certificate Authority

Some installations do not use a self-signed certificate. Instead, the server certificate is issued by the customer's own internal certificate authority. The Goodyear production server (usam1807lalc01.corp.pep.pvt) is one such case, using a chain of three certificates:

USAM1807LALC01.corp.pep.pvt      server certificate ("leaf")
  issued by PepsiCoCA01          intermediate
    issued by PepsiCoRootCA      root

On these sites, no certificate installation is required on managed client machines: the corporate root is already distributed to them, so the connection is trusted out of the box. Two rules matter here:

• Never install the server certificate itself. The leaf is not a certificate authority, so importing it into the trusted root store has no effect. If a machine is not managed by the corporate domain and does not trust the connection, import the root certificate (PepsiCoRootCA) instead, using the same PowerShell, certutil or MMC steps described above.
• The server must send the intermediate certificate. A client can only verify the connection if it can build a path from the server certificate up to the root. The leaf alone is not sufficient — the client also needs the intermediate and will not fetch it by itself.

Checking Whether a Client Machine Trusts the Server

Run this in PowerShell on the client machine. It needs no extra tools:

$server = "usam1807lalc01"; $port = 8443
$tcp = [System.Net.Sockets.TcpClient]::new($server, $port)
$ssl = [System.Net.Security.SslStream]::new($tcp.GetStream(), $false, { param($s, $cert, $chain, $errors)
    Write-Host "Result: $errors"
    foreach ($st in $chain.ChainStatus) { Write-Host "  $($st.Status): $($st.StatusInformation)" }
    return $true })
$ssl.AuthenticateAsClient($server); $ssl.Close(); $tcp.Close()

Interpret the output as follows:

A common misdiagnosis: importing PepsiCoCA01 (the intermediate) into the trusted root store does not fix UntrustedRoot. Only PepsiCoRootCA belongs there. Verify what is actually installed:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -match "PepsiCo" |
    Select-Object Subject, NotAfter

Checking What the Server Sends

The check above cannot answer this, because Windows completes the chain on its own — using certificates already in the local store and by downloading missing ones. A server that sends an incomplete chain can therefore still appear to work on one machine and fail on the next.

To see the certificates the server actually transmits, use openssl from a Git Bash prompt (openssl is not on the Windows PATH, but ships with Git for Windows at C:\Program Files\Git\usr\bin\openssl.exe):

echo | openssl s_client -connect usam1807lalc01:8443 -servername usam1807lalc01

The Certificate chain section must list two entries — the leaf and the intermediate. If only the leaf appears, the server's certificate file needs to be rebuilt as a full chain.

Note for Python Clients

Python does not use the Windows certificate store. The requests library ships its own list of public certificate authorities, which by design never contains a corporate root. A request therefore fails with SSLCertVerificationError: unable to get local issuer certificate even when the same URL works in the browser. Point verify at the root certificate file:

requests.get("https://usam1807lalc01:8443/api/", verify="PepsiCoRootCA.crt")

Do not work around this with verify=False — that disables verification entirely and leaves the connection open to interception. Alternatively, install the pip-system-certs package to make Python use the Windows store.

Additional Requirements

• Matching hostname: The client must call the exact hostname listed in the certificate's subjectAltName (SAN), not a raw IP address or a different alias.
• TLS version: Older .NET Framework clients may default to an outdated protocol. Force TLS 1.2 in the client code:

csharp ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; * Certificate validity: Ensure the certificate is not expired and the client machine's date and time are correct, as certificate validation is time-dependent.