During the SSL/TLS session in most cases the server sends an X.509 certificate to the client. This certificate is aimed to prove that the client has connecte to the legitimate server (not a fraud).
Certificate validation procedure on the client verifies that the server whose host name and the name in the presented certificate match. This requires that the server has acquired a valid CA-signed (we omit self-signed variants for lack of security and flexibility) certificate for the needed host name. So far so good.
Trust can be given to the verification process due to the hierarchical nature of Public Key Infrastructure (PKI) which includes Certificate Authorities (CA) that issue and sign X.509 certificates for end entities and other authorities. The client trusted certain (rather small) set of trusted root CAs and then it trusts certificates issued or signed by those CAs.
The problem with the above scheme is that if you trust the CA, you also trust all of cerificates issued by this CA and all sub-CAs and end entities, for which the trusted root CA has issued certificates.
This scheme worked when identity validation rules imposed by CAs were strict and the number of CAs was small. Unfortunately as Internet grew up, both state authorities and hackers have started to abuse the architecture by creating fake certificates for very popular sites, and the performing MITM (Man In The Middle) attacks using those certificates. Such certificates would be validated because technically they are valid. But these are not "real" certificates.
Here's where Certificate Pinning comes to play. Certificate Pinning is the procedure where the client holds a copy of the trusted information about the expected server certificate and uses this information as an additional protection step after regular certificate validation. The stored information can be a copy of the server's certificate, information about certificate issuer etc. . I.e. this is what confirms that the certificate presented by the server is likely to be "real" and not forged in the deep cellars of russian KGB. For example, if you build a client-server system and you use only well-known CAs such as Globalsign or Verisign for obtaining server certificates, you can add the expected issuer names to the client software and compare those names with the name of the CA of the received certificate of the server.
Pinning can cover one or several certificates (when you store the hash of the server's certificates or the certificates themself in the client software) or a wider group of certificates (when you store just the expected root CA name or intermediate CA names and trust all certificates if issued by those CAs).
Pinning one or several certificate is not very flexible because if the certificate expires or is revoked, you will need to immediately update all installations of the client software. Pinning a class of certificates seems to be a better idea.
Certificate Pinning and SecureBlackbox
In SecureBlackbox you most likely validate certificates using TElX509CertificateValidator class. This class lets you specify the certificates you trust explicitly (AddTrustedCertificates method) and certificates you know but still want to validate as usually (AddKnownCertificates method). By default on Windows TElX509CertificateValidator class also makes use of Windows built-in certificate stores with trusted and known certificates, but this use can be disabled by setting UseSystemStorages property to false.
So to "pin" one or several certificates you just add them to the list of trusted certificates using AddTrustedCertificates method and disable use of system storages via UseSystemStorages property.
If you hold just certificate hashes or other information (accepted CA names etc.), the procedure is different. TElX509CertificateValidator class has OnAfterCertificateValidation event which you need to handle. In your event handler you must compare the information you have and trust with the information passed to the event handler, and adjust Validity and ValidityReason parameters if needed. This method can be used also if you have a fixed set of certificates -- in the event handler you can compare the passed certificate with the certificate(s) that you have.
Limitations of the method
When you store the certificate information in the client software you must pay special attention to ensure that your users obtain this client software from the legitimate source and that they get unaltered software. This includes signing the installation package (if possible) with your code signing certificate, providing SHA hashes and OpenPGP signatures that correspond to the files on the site (note that if the attacker can replace your installation package on the site, they will also replace the hash or the signature), sending clients the software burned on the CD-ROM or DVD-ROM disk and taking similar actions. Educating clients about the basics of secure computing is also warmly welcome.