Skip to main content

Security and HTTPS

Test Services is a web application, so the way it secures the traffic between your browser and the machine it runs on matters. It uses HTTPS by default and relies on the wider OpenLab platform for identity and storage security. This page explains that model so you understand what is protected out of the box and what an administrator can change. For the addresses you use to reach Test Services, see Log in to Test Services.

HTTPS by default​

Test Services communicates over HTTPS for all web traffic, with no extra configuration. Secure transport is active out of the box, and plain HTTP is not offered: there are no HTTP addresses to fall back to. This means traffic between your browser and Test Services is encrypted whether you open it locally or from another machine in the lab.

Out of the box, Test Services is reachable through a certificate issued by the OpenLab platform's own certificate authority. The exact address and port depend on the machine's role in the deployment. A client is reached on a dedicated port, while a server, AIC, or workstation is reached on the standard HTTPS port through a reverse proxy. Because of this, using a client-only address on a server, or an old address from before an upgrade, fails. The current addresses are listed in Log in to Test Services.

note

If a firewall protects a client machine, the client's Test Services port must be open for the application to be reachable from other machines.

How certificates are managed​

The certificate that secures Test Services is managed by Windows and the OpenLab platform rather than by Test Services itself. This lets your organization replace the default certificate with a commercial certificate from a trusted authority, and lets the operating system apply security updates to the transport layer independently of Test Services. Installing a third-party certificate is an administrator task documented as part of OpenLab platform setup.

Because certificate and port handling belong to the platform, Test Services does not carry its own certificate or port options. An administrator works with the OpenLab Server certificate configuration, not a Test Services-specific tool.

Security beyond transport​

Encrypting traffic is only one part of the picture. Test Services depends on the OpenLab platform for the rest:

  • Identity. Test Services validates credentials against OpenLab Shared Services and checks that you hold the right role before letting you run tests. See About authentication and Roles and privileges.
  • A required session. Whether login is required is determined by the deployment, and Test Services defaults to requiring it. Login is absent only on a file-based Workstation deliberately configured without security, which is a narrower configuration with reduced protection and in which the Security Test is not available.
  • Stored evidence. Reports and result files are written to the OpenLab storage backend, which provides the access controls and integrity guarantees for that data.

Keeping Test Services current matters for security too, because transport and dependency fixes are delivered through OpenLab CDS releases. For what each release changed, see Release notes.

See also​