Which Certificate Do I Need?¶
People who get stuck with QIE certificates almost always have one of two cases. Identify which one applies, then send only what the case calls for.
Case 1, Standard TLS. One side is the server, the other is the client. Only the server needs a private key.
- If you are the server (a vendor connects in to QIE): generate a private key in QIE, generate a CSR, get it signed by a trusted certificate authority (or self-sign), and send the vendor your public certificate. The private key stays in QIE.
- If you are the client (QIE connects out to a vendor): import the vendor's public certificate into QIE. You do not need a private key for this case.
Case 2, Client-authenticated (mutual) TLS. Both sides authenticate each other, so both sides have a private key and both sides exchange public certificates.
- Generate a private key in QIE, generate a CSR, get it signed (or self-sign), and send the vendor your public certificate. The private key stays in QIE.
- Import the vendor's public certificate into QIE so QIE trusts the vendor's side of the handshake.
- On the channel's connection, enable Client Auth and select your certificate so QIE presents it during the handshake.
Only the public certificate ever leaves QIE
In every case above, only the public certificate is sent to the vendor. The private key stays in QIE. A vendor who asks for your private key is asking for the wrong thing. What they actually need is the public certificate. Anyone in possession of your private key can impersonate your server, decrypt traffic encrypted to your public certificate, and sign data as you.
Certificates in the HTTPS listener Server Cert dropdown
The Server Cert dropdown on the HTTP Listener and Secure Socket receiver only lists certificates that have their matching private key available in QIE. Imported public-only certificates (the kind you receive from a partner or download for trust-store use) do not appear because QIE cannot complete a TLS handshake with them (the server side of TLS needs the private key to sign the handshake). If a certificate you expect to see is missing, verify the matching private key was imported alongside it (or a paired key/cert PKCS12 file was used) on the Certificate Management page.
Both Directions of a Two-Way Integration¶
A partner integration where traffic flows both ways is two independent TLS relationships, not one. Each direction has its own server, its own client, and its own pair of certificates. Work out the four roles before requesting anything.
| Direction | TLS server | TLS client | QIE configuration |
|---|---|---|---|
| QIE calls the partner API | The partner | QIE | Web Service Connection: the partner certificate or its issuing CA under Trust Policy, QIE's own certificate under Client Auth |
| The partner calls QIE | QIE | The partner | HTTP Listener: Secure enabled, QIE's certificate under Server Cert, the partner certificate or its issuing CA under Client Auth |
QIE holds a private key in both directions, but the two certificates play different roles. The one selected under Client Auth on a Web Service Connection proves QIE's identity when QIE calls out. The one selected under Server Cert on an HTTP Listener proves QIE's identity when the partner calls in. They can be the same certificate where the names allow it, and they are ordinarily separate.
Who Should Operate the Certificate Authority¶
The party that owns the server decides which certificate authorities it trusts for incoming clients, so the usual arrangement is that each organization issues the client certificates its own systems present:
- The partner issues the client certificate QIE presents when calling the partner API. QIE generates the private key and the CSR, the partner signs the CSR, and QIE imports the signed certificate. The private key never leaves QIE.
- The partner issues the client certificate its own backend presents when calling the QIE listener, and gives QIE only the issuing CA certificate to trust.
A CSR carries the public key and identifying information. It never carries the private key, which is why a CSR is the correct thing to send to a certificate authority. Some organizations require every identity reaching their environment to be issued by their own enterprise CA. That arrangement works, and it costs a separate certificate lifecycle for each partner.
See Certificate Management for generating a key and CSR in QIE and importing the signed result.