TsgcUDPCLient › Propriedades › DTLSOptions
Configurações de certificado, verificação e OpenSSL aplicadas quando o DTLS está habilitado.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Agrupa os parâmetros que controlam o handshake DTLS. RootCertFile é o repositório de certificados confiáveis usado para verificar a outra ponta, o mesmo significado que esta propriedade tem nos transportes TLS e QUIC. CertFile é o certificado deste cliente, e lê um arquivo que contém o certificado junto com os seus intermediários, portanto um arquivo de cadeia funciona. KeyFile é a chave privada que acompanha CertFile. VerifyCertificate alterna a validação do certificado do servidor e VerifyDepth limita o comprimento da cadeia de certificados. Quando VerifyCertificate é True e RootCertFile está vazio, o repositório de certificados do sistema operacional é usado como âncora de confiança. OpenSSL_Options seleciona a versão da API OpenSSL (oslAPI_1_1 ou oslAPI_3_0) e a pasta de onde as bibliotecas OpenSSL são carregadas. Essas configurações entram em vigor apenas quando DTLS é True e são ignoradas para tráfego UDP simples.
IOHandler (padrão iohOpenSSL) seleciona o mecanismo DTLS. iohNativeTLS roda o handshake e os registros sobre o mecanismo DTLS 1.2 nativo do pacote sgcCrypto, portanto nenhuma biblioteca OpenSSL é carregada. Suporta apenas as cifras AEAD ECDHE (AES-128-GCM, AES-256-GCM e ChaCha20-Poly1305) com certificados ECDSA ou RSA sobre X25519, P-256 ou P-384, exige Extended Master Secret e não retoma sessões. CertFile e KeyFile podem ser PEM ou DER. Usar iohNativeTLS em uma build sem o pacote sgcCrypto gera um erro. Qualquer outro valor mantém o caminho OpenSSL. OnDTLSVerifyPeer não é disparado no caminho nativo, pois não há objeto de certificado OpenSSL para passar. Quando VerifyCertificate é True, a cadeia é verificada contra RootCertFile ou as raízes do sistema, e o TsgcDTLS_Component, o mecanismo DTLS por trás deste componente, dispara seu evento OnVerifyPeerNative nesse caso, com a cadeia do peer em DER (folha primeiro), o veredito e um var Accept. Veja Executar sem OpenSSL.
RootCertFile mudou de significado, e esta é uma alteração incompatível. Antes ele era carregado como o certificado deste endpoint, o que era inconsistente com o restante da biblioteca. Uma configuração que indica um certificado em RootCertFile e uma chave em KeyFile deixando CertFile vazio agora gera um erro quando o componente é iniciado:
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.
Para atualizar essa configuração, mova o caminho do certificado de RootCertFile para CertFile e deixe RootCertFile para a autoridade certificadora com a qual a outra ponta é verificada. O erro é deliberadamente fatal. Sem ele, o cliente apresentaria silenciosamente um certificado autoassinado gerado com um fingerprint diferente a cada execução.
VerifyCertificate agora é aplicado. Anteriormente o resultado da verificação era calculado e depois descartado, portanto, com a verificação ativada, qualquer certificado era aceito, inclusive um emitido por uma autoridade não confiável. Uma cadeia que falha agora encerra o handshake. VerifyCertificate continua sendo False por padrão, portanto a configuração padrão permanece inalterada.
O TsgcRTCPeerConnection não é afetado. O WebRTC autentica a outra ponta pelo fingerprint transportado no SDP, e não por uma cadeia de certificados, e deixa VerifyCertificate desabilitado. Essa é a configuração normal do WebRTC e continua funcionando exatamente como antes.
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;