The LocalCertificate specifies the certificate to present to the remote entity when initiating an association (when acting as a receiver, use ListenSecure, which includes a certificate in it’s parameters).  If UseTLS is true, but this property is null, then an anonymous association attempt will be made, which may or may not be accepted by the remote entity.

RemoteCertificate allows an application to verify the certificate presented by the remote entity, which may be done in 3 ways:

When receiving an incoming association in AssociationRequest2, the remote certificate is available as a property of the new incoming association, allowing an accept/reject decision to be made based on it’s contents (it may be NULL if an anonymous association has been attempted).
 After making an outgoing association using SetDestination, the remote certificate is available once this operation has completed (during ActionComplete or one isReady is true).  This is the correct place for a client to validate the server before performing sensitive transactions, as it protects against a “man-in-the-middle” attack.

After an outgoing DicomQuery based operation has completed, this property indicates the certificate which has been provided.  Note of course, that this is useful only for auditing, not control, as it is available only after data has been exchanged, so in a proper secure application, the DicomQuery based methods should be replaced by their DicomConnection based equivalents, which allow prior validation.

For more information on using X509 certificates in DicomObjects, see Certificates

DicomConnection Object  | DicomConnection Members