TsgcUDPCLient › Properties › DTLSOptions
Impostazioni relative a certificato, verifica e OpenSSL applicate quando DTLS è abilitato.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Raggruppa i parametri che gestiscono l'handshake DTLS. RootCertFile è l'archivio attendibile usato per verificare l'altro estremo, lo stesso significato che questa proprietà ha nei trasporti TLS e QUIC. CertFile è il certificato di questo client e legge un file che può contenere il certificato insieme ai suoi intermedi, quindi un file di catena funziona. KeyFile è la chiave privata associata a CertFile. VerifyCertificate attiva la validazione del certificato server e VerifyDepth limita la lunghezza della catena di certificati. Quando VerifyCertificate è True e RootCertFile è vuoto, viene usato come ancora di fiducia l'archivio certificati del sistema operativo. OpenSSL_Options seleziona la versione dell'API OpenSSL (oslAPI_1_1 o oslAPI_3_0) e la cartella da cui vengono caricate le librerie OpenSSL. Queste impostazioni hanno effetto solo quando DTLS è True e vengono ignorate per il traffico UDP normale.
IOHandler (predefinito iohOpenSSL) seleziona il motore DTLS. iohNativeTLS esegue l'handshake e i record sul motore DTLS 1.2 nativo del pack sgcCrypto, quindi non viene caricata alcuna libreria OpenSSL. Supporta solo le cipher suite AEAD ECDHE (AES-128-GCM, AES-256-GCM e ChaCha20-Poly1305) con certificati ECDSA o RSA su X25519, P-256 o P-384, richiede Extended Master Secret e non riprende le sessioni. CertFile e KeyFile possono essere PEM o DER. Avviare con iohNativeTLS in una build senza il pack sgcCrypto genera un errore. Qualsiasi altro valore mantiene il percorso OpenSSL. OnDTLSVerifyPeer non viene attivato sul percorso nativo, perché non esiste un oggetto certificato OpenSSL da passare. Quando VerifyCertificate è True la catena viene verificata rispetto a RootCertFile o alle radici di sistema, e TsgcDTLS_Component, il motore DTLS dietro questo componente, genera lì il proprio evento OnVerifyPeerNative, con la catena del peer in DER (foglia per prima), il verdetto e un var Accept. Vedere SSL senza OpenSSL.
RootCertFile ha cambiato significato, e si tratta di una modifica non retrocompatibile. In precedenza veniva caricato come certificato di questo endpoint, cosa incoerente con il resto della libreria. Una configurazione che indica un certificato in RootCertFile e una chiave in KeyFile lasciando CertFile vuoto genera ora un errore all'avvio del componente:
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.
Per aggiornare una configurazione di questo tipo, spostare il percorso del certificato da RootCertFile a CertFile e lasciare in RootCertFile l'autorità di certificazione con cui viene verificato l'altro estremo. L'errore è volutamente fatale. Senza di esso il client presenterebbe silenziosamente un certificato autofirmato generato al momento, con un'impronta diversa a ogni esecuzione.
VerifyCertificate è ora applicato. In precedenza il risultato della verifica veniva calcolato e poi scartato, quindi con la verifica attiva qualsiasi certificato veniva accettato, compreso uno emesso da un'autorità non attendibile. Una catena non valida ora interrompe l'handshake. VerifyCertificate resta False per impostazione predefinita, quindi la configurazione predefinita non cambia.
TsgcRTCPeerConnection non è interessato. WebRTC autentica l'altro estremo tramite l'impronta trasportata nell'SDP e non tramite una catena di certificati, e lascia VerifyCertificate disabilitato. Questa è la configurazione WebRTC normale e continua a funzionare esattamente come prima.
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;