The connection fails with 08S01 "UntrustedRoot"

A connection over https fails immediately with SQLSTATE 08S01 and the message (the service is unreachable: the secure connection (TLS) couldn't be established; most common reason: the service's certificate isn't registered as trusted on this computer):

Der Dienst ist nicht erreichbar: Die gesicherte Verbindung (TLS) kam nicht zustande - … UntrustedRoot …
Haeufigster Grund: Das Zertifikat des Dienstes ist auf diesem Rechner nicht als vertrauenswuerdig eingetragen.

Access shows only „ODBC–connection to … failed“ (3151); the message above is then in the driver's trace.

Driver in both bitnesses, any application; service with a certificate that doesn't come from a public certification authority (your own corporate CA, self-signed).

The driver validates the service's certificate against the Windows certificate stores. If this workstation doesn't know the issuing authority, the connection stops. There's deliberately no switch to turn off the validation: a disabled validation would send keys, passwords, and codes to anyone who places themselves between the workstation and the service. The driver doesn't retry – an untrusted certificate is the same three seconds later.

1. Find out who issued the certificate: ask the operator of the service, or open the service address in a browser and look at the certificate.
2. If it comes from a corporate CA, deploy its root certificate to all workstations through Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
3. For a single workstation, for example for testing, import the root certificate as an administrator under Local Computer > Trusted Root Certification Authorities.
4. In the long run, give the service a certificate from a public authority; the data service's installation package includes retrieval through Let's Encrypt for this. Then nothing needs to be deployed to the workstations.

Bitness doesn't matter: the x86 and x64 drivers read the same certificate stores.

Open the service address (…/odata/v4/) in Edge or Chrome on the same workstation; both validate certificates against the Windows certificate stores as the driver does. (A browser with its own certificate store isn't suitable for this test.) No certificate warning appears. After that, the driver connects, and the trace shows the service's response to $metadata instead of the TLS message.

• Sign in with a personal key and a second factor
• Driver connection string: `URL`, `TRACEFILE`
• Turn on tracing