Certificate
The Certificate feature in Qntrl ensures secure communication when using Outbound REST and Outbound SOAP web services. It helps verify the authenticity of external servers during API calls, especially for HTTPS requests that require SSL (Secure Socket Layer) encryption.
By managing certificates, Qntrl establishes trust between the client and server, supports secure data transfer, and enables mutual TLS (mTLS) authentication when needed.
Why Use Certificates?
- Establish SSL-enabled secure communication for all outbound requests.
- Support HTTPS-based APIs where the server presents a certificate and the client must validate it.
- Enable mutual authentication: both the client and the server validate each other’s certificates.
- Test HTTPS requests even in environments where default certificate authorities are unavailable or insufficient.
Benefits
- Keeps data safe: It protects sensitive details shared between users and the service.
- Builds trust: Users feel more confident using a service when they know it’s secure.
- Supports compliance: Many security standards and regulations require certificates for data protection.
- Improves access: Some browsers block or warn users about sites that don’t have a valid certificate.
How Mutual Authentication Works
Mutual authentication (mTLS) enhances security by ensuring that both the client and the server verify each other’s identities during the SSL/TLS exchange process.
- Client Authentication: During the exchange, the client presents its certificate to the server.
- Server Verification: The server validates the client's certificate against its trust store.
- Server Authentication: Simultaneously, the server shares its certificate with the client.
- Client Verification: The client then verifies the server’s certificate using its own trust store.
- If both verifications succeed, a secure SSL/TLS connection is established, allowing trusted communication between the two parties.
Before enabling mutual authentication, administrators must configure the necessary Key Store and Trust Store certificates.
Key Store in Qntrl
A Key Store securely stores the client’s private key and its associated certificate, which are used to authenticate the client to the server.
Qntrl supports two formats for Key Stores:
Qntrl supports two formats for Key Stores:
- Certificate and Private Key (uploaded separately)
- PFX / PKCS#12 files (bundled format)
Trust Store in Qntrl
A Trust Store contains the public certificates of trusted servers. When Qntrl makes an outbound call (e.g., to a server with a self-signed certificate), the server’s certificate must be trusted to establish a secure SSL connection.
By uploading the service provider’s certificate into Qntrl’s trust store, you ensure that all outbound HTTPS requests validate the server’s authenticity. Similarly, when Qntrl connects to a client, the client must trust the server’s certificate, particularly when it is self-signed.
Create a Certificate
To create a new certificate in Qntrl, navigate to(settings)>> Advanced >> Certificate >> Click New Certificate.
Fill in the certificate details:
- Name: Enter a unique name for the certificate.
- Certificate Type: Choose the appropriate certificate type based on how the client initiates requests:
- Certificate & Key: Requires separate certificate key and private key files.
- Certificate File
- Private Key File
- PFX/PKCS312: A single file containing both certificate and private key.
- PFX / PKCS#12 File
- Trust Store: Used in cases where both client and server must trust each other’s certificates.
- Truststore File
- Certificate Format : Choose one of the following:
- PEM: Human-readable Base64 encoded format (commonly used).
- DER: Binary format used in certain systems.
- Password : If your certificate requires a password, enter it here. This is applicable for PFX/PKCS format.
- Host: Enter the hostname (e.g., core.qntrl.com) for which the certificate applies.
- Port: Default is 443. Modify if your API uses a different port.
- Click Save to create the certificate.
When executing the request, the matching certificate for the specific host and port is retrieved. If there are multiple matches, the latest will be used.
Once saved, Qntrl auto-generates and displays the following certificate details:
Subject
Issuer
Valid From
Expires On
In secure production environments, certificates are typically issued by trusted Certificate Authorities (CAs). In testing or sandbox setups like Bridge, dummy or self-signed certificates are often used instead.Using Certificates in Outbound REST APIs
Navigate to
(settings)>> WEB SERVICES >> Outbound >> Click REST.
- Navigate to the Settings tab.
- Enable the Enable SSL Certificate Verification toggle.
- The system retrieves the client certificate and trust store certificate, then validates the certificate against the host configured in the certificate section.
- If the client certificate or host does not match, the API call will fail with an SSL Certificate Not Found error.
Incorrect passwords, hostnames, or expired certificates will result in failed requests.
Edit/ Delete a Certificate
To modify or remove a certificate:
- Navigate to
- Click the action menu (...) next to the certificate name.
- Choose Edit or Delete:
- Edit: Select this option to make changes to the certificate details. After editing, click Save to apply the changes.
- Delete: Use this option to permanently remove unused or invalid certificates from your account.
Deleting a certificate is irreversible. Make sure it’s no longer in use before proceeding.
Troubleshooting
1. SSL Certificate Not Found
Ensure the host name in the certificate matches the one in the API configuration.
Verify that SSL Certificate Verification is enabled under Settings.
2. Invalid Certificate Format
Check if the correct format (PEM/DER) is selected while uploading.
3. Password Errors
If your certificate is password-protected, ensure the correct password is entered.
4. Expired Certificates
Validate the expiry date of the certificate in the properties section and renew if necessary.
5. PLS Errors
Occur when the server certificate isn’t trusted by Java’s default trust store. Use Trust Store to load custom server certificates manually.
Related Articles
Bridge agent settings
Once the Bridge agent is set up, you can log in to the bridge agent to view and modify the allowed configuration as needed. To do this: In Qntrl, navigate to (settings) >> Advanced >> Bridge, then select your bridge. Hover your cursor over the bridge ...Troubleshooting
1. Cannot execute API Make sure all required fields are filled in correctly — this includes the URL, query parameters, headers, and request body. Missing or incorrect values can prevent the API from executing successfully. 2. Unauthorized or ...Active Directory(AD)
Active Directory (AD) is a service developed by Microsoft that provides a centralized way to manage all your network machines, users, and resources in one place. Active Directory stores data as Objects, which include users, groups, applications, and ...Configure Outbound REST Web Service
Outbound REST Web Services enables users to interact with external web services by sending HTTP requests to retrieve, create, update, or delete data on REST-compliant servers. This functionality is designed to integrate seamlessly with external APIs ...White Labeling
Early Access White Labeling for Qntrl is not enabled for all users. If you'd like to try it out, please email our support team for early access. White Label allows organizations to completely rebrand Qntrl to reflect their organization’s brand ...
You are currently viewing the help articles of Qntrl 3.0. If you are still using our older version and require guidance with it, Click here.