TsgcUDPCLient › Properties › DTLSOptions
Certificaat-, verificatie- en OpenSSL-instellingen die worden toegepast wanneer DTLS is ingeschakeld.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Groepeert de parameters die de DTLS-handshake aandrijven. RootCertFile is het certificaatarchief dat wordt gebruikt om de tegenpartij te verifiëren, dezelfde betekenis die deze eigenschap heeft op de TLS- en QUIC-transporten. CertFile is het certificaat van deze client, en het leest een bestand dat het certificaat samen met de intermediaire certificaten bevat, dus een ketenbestand werkt. KeyFile is de privésleutel die bij CertFile hoort. VerifyCertificate schakelt servercertificaatvalidatie in en VerifyDepth beperkt de lengte van de certificaatketen. Wanneer VerifyCertificate True is en RootCertFile leeg is, wordt het certificaatarchief van het besturingssysteem als vertrouwensanker gebruikt. OpenSSL_Options selecteert de OpenSSL API-versie (oslAPI_1_1 of oslAPI_3_0) en de map waaruit de OpenSSL-bibliotheken worden geladen. Deze instellingen worden alleen van kracht wanneer DTLS True is en worden genegeerd voor gewoon UDP-verkeer.
IOHandler (standaard iohOpenSSL) selecteert de DTLS-engine. iohNativeTLS voert de handshake en de records uit op de native DTLS 1.2-engine van het sgcCrypto-pack, zodat er geen OpenSSL-bibliotheek wordt geladen. Deze ondersteunt alleen de ECDHE AEAD-ciphersuites (AES-128-GCM, AES-256-GCM en ChaCha20-Poly1305) met ECDSA- of RSA-certificaten over X25519, P-256 of P-384, vereist Extended Master Secret en hervat geen sessies. CertFile en KeyFile mogen PEM of DER zijn. Starten met iohNativeTLS in een build zonder het sgcCrypto-pack geeft een fout. Elke andere waarde behoudt het OpenSSL-pad. OnDTLSVerifyPeer wordt niet geactiveerd op het native pad, omdat er geen OpenSSL-certificaatobject is om door te geven. Wanneer VerifyCertificate True is, wordt de keten gecontroleerd tegen RootCertFile of de systeem-rootcertificaten, en genereert TsgcDTLS_Component, de DTLS-engine achter dit component, daar in plaats daarvan zijn OnVerifyPeerNative-event, met de peerketen in DER (leaf eerst), het oordeel en een var Accept. Zie SSL zonder OpenSSL.
RootCertFile heeft een andere betekenis gekregen, en dat is een breaking change. Het werd voorheen geladen als het certificaat van dit eindpunt, wat niet strookte met de rest van de bibliotheek. Een configuratie die een certificaat in RootCertFile en een sleutel in KeyFile noemt terwijl CertFile leeg blijft, genereert nu een fout wanneer het component start:
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.
Om zo'n configuratie bij te werken verplaatst u het certificaatpad van RootCertFile naar CertFile en houdt u RootCertFile voor de certificaatautoriteit waartegen de tegenpartij wordt geverifieerd. De fout is bewust fataal. Zonder die fout zou de client stilzwijgend een gegenereerd zelfondertekend certificaat presenteren met bij elke start een andere vingerafdruk.
VerifyCertificate wordt nu afgedwongen. Voorheen werd het verificatieresultaat berekend en vervolgens verworpen, zodat met verificatie ingeschakeld elk certificaat werd geaccepteerd, ook een certificaat dat door een niet-vertrouwde autoriteit was uitgegeven. Een keten die niet valideert beëindigt nu de handshake. VerifyCertificate is nog steeds standaard False, dus de standaardconfiguratie is ongewijzigd.
TsgcRTCPeerConnection wordt hier niet door geraakt. WebRTC authenticeert de tegenpartij op basis van de vingerafdruk in de SDP en niet op basis van een certificaatketen, en laat VerifyCertificate uitgeschakeld. Dat is de normale WebRTC-configuratie en die blijft precies werken zoals voorheen.
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;