TsgcUDPCLient › Properties › DTLSOptions
Certificate, verification and OpenSSL settings applied when DTLS is enabled.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Groups the parameters that drive the DTLS handshake. RootCertFile is the trust store used to verify the other end, the same meaning this property has on the TLS and QUIC transports. CertFile is the certificate of this client, and it reads a file that holds the certificate together with its intermediates, so a chain file works. KeyFile is the private key that goes with CertFile. VerifyCertificate toggles server certificate validation and VerifyDepth limits the length of the certificate chain. When VerifyCertificate is True and RootCertFile is empty, the certificate store of the operating system is used as the trust anchor. OpenSSL_Options selects the OpenSSL API version (oslAPI_1_1 or oslAPI_3_0) and the folder where the OpenSSL libraries are loaded from. These settings take effect only when DTLS is True and are ignored for plain UDP traffic.
RootCertFile changed meaning, and this is a breaking change. It was previously loaded as the certificate of this endpoint, which was inconsistent with the rest of the library. A configuration that names a certificate in RootCertFile and a key in KeyFile while leaving CertFile empty now raises an error when the component starts:
DTLS_error: RootCertFile is the trust store used to verify the other end, not this endpoint's own certificate. Set CertFile to the certificate that goes with KeyFile.
To update such a configuration, move the certificate path from RootCertFile to CertFile, and leave RootCertFile for the certificate authority that the other end is verified against. The error is deliberately fatal. Without it the client would silently present a generated self-signed certificate with a different fingerprint on every run.
VerifyCertificate is now enforced. Previously the verification result was computed and then discarded, so with verification switched on any certificate was accepted, including one issued by an untrusted authority. A failing chain now terminates the handshake. VerifyCertificate is still False by default, so the default configuration is unchanged.
TsgcRTCPeerConnection is not affected. WebRTC authenticates the other end by the fingerprint carried in the SDP, not by a certificate chain, and leaves VerifyCertificate off. That is the normal WebRTC configuration and it keeps working exactly as before.
oClient.DTLS := True;
oClient.DTLSOptions.CertFile := 'client.pem';
oClient.DTLSOptions.KeyFile := 'client.key';
oClient.DTLSOptions.VerifyCertificate := True;
oClient.DTLSOptions.OpenSSL_Options.APIVersion := oslAPI_3_0;