Implement SSL certificate pinning
Technical Note: Certificate pinning guidance and advisory
Guidance:
As part of our commitment to delivering a fully RFC-compliant SSL/TLS stack, TrustCore SDK provides support for certificate pinning. This feature exists to maintain standards compatibility and to enable interoperability in specialized environments — such as memory-constrained IoT devices, where maintaining a full CA trust store chain may not be feasible.
Advisory:
Certificate pinning is included for technical completeness but is not recommended for general use.
The practice introduces significant operational risks and maintenance complexity.
Customers should instead rely on standard PKI validation, automated trust management, and certificate transparency.
These approaches represent the best security practices for long-term reliability and maintainability.
Understanding Certificate Pinning
As part of enhancing the security of SSL/TLS communications, SSL certificate pinning can be an important element in your security strategy.
Certificate pinning involves hard-coding the certificate that is known to be used by the server within the client application. During the SSL handshake, the presented server certificate is matched against this pre-configured certificate in the client’s keystore.
The key points of certificate pinning include: - The client application is explicitly aware of the server’s certificate. - Any mismatch between the expected certificate and the presented certificate during the handshake will lead to the client terminating the session, thereby preventing man-in-the-middle attacks.
Notice
There are no specific build flags required to implement certificate pinning.
Configuring Certificate Pinning
Follow these steps to set up certificate pinning:
In your client application, make use of the
CERT_STORE_addTrustPointAPI function to add the server’s certificate that you want to pin against. This is done so that the client trusts the server certificate without needing to validate the entire certificate chain.
By executing this process, you are directly validating the server certificate as trusted during the SSL handshake. This means that the typical chain of trust validation is not performed, and the session security relies on the match of the hardcoded certificate.