TsgcUDPCLient › Właściwości › DTLSOptions
Ustawienia certyfikatu, weryfikacji i OpenSSL stosowane przy włączonym DTLS.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Grupuje parametry sterujące uzgadnianiem DTLS. RootCertFile to magazyn zaufania używany do weryfikacji drugiej strony, czyli to samo znaczenie, jakie ta właściwość ma w transportach TLS i QUIC. CertFile to certyfikat tego klienta i odczytuje plik zawierający certyfikat razem z certyfikatami pośrednimi, więc plik z łańcuchem również działa. KeyFile to klucz prywatny pasujący do CertFile. VerifyCertificate przełącza weryfikację certyfikatu serwera, a VerifyDepth ogranicza długość łańcucha certyfikatów. Gdy VerifyCertificate ma wartość True, a RootCertFile jest puste, jako kotwica zaufania używany jest magazyn certyfikatów systemu operacyjnego. OpenSSL_Options wybiera wersję API OpenSSL (oslAPI_1_1 lub oslAPI_3_0) oraz folder, z którego są ładowane biblioteki OpenSSL. Ustawienia te mają zastosowanie tylko wtedy, gdy DTLS ma wartość True, i są ignorowane dla zwykłego ruchu UDP.
IOHandler (domyślnie iohOpenSSL) wybiera silnik DTLS. iohNativeTLS uruchamia uzgadnianie i rekordy na natywnym silniku DTLS 1.2 pakietu sgcCrypto, więc żadna biblioteka OpenSSL nie jest wczytywana. Obsługuje wyłącznie zestawy szyfrów AEAD ECDHE (AES-128-GCM, AES-256-GCM i ChaCha20-Poly1305) z certyfikatami ECDSA lub RSA na krzywych X25519, P-256 lub P-384, wymaga Extended Master Secret i nie wznawia sesji. CertFile i KeyFile mogą być w formacie PEM lub DER. Uruchomienie z iohNativeTLS w kompilacji bez pakietu sgcCrypto zgłasza błąd. Każda inna wartość zachowuje ścieżkę OpenSSL. OnDTLSVerifyPeer nie jest wywoływane na ścieżce natywnej, ponieważ nie ma obiektu certyfikatu OpenSSL do przekazania. Gdy VerifyCertificate ma wartość True, łańcuch jest sprawdzany względem RootCertFile lub certyfikatów systemowych, a TsgcDTLS_Component, silnik DTLS stojący za tym komponentem, zgłasza w to miejsce swoje zdarzenie OnVerifyPeerNative, z łańcuchem partnera w formacie DER (od liścia), werdyktem i parametrem var Accept. Zobacz Praca bez OpenSSL.
RootCertFile zmieniło znaczenie i jest to zmiana niezgodna wstecz. Wcześniej było wczytywane jako certyfikat tego punktu końcowego, co było niespójne z resztą biblioteki. Konfiguracja, która wskazuje certyfikat w RootCertFile i klucz w KeyFile, pozostawiając puste CertFile, zgłasza teraz błąd przy uruchamianiu komponentu:
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.
Aby zaktualizować taką konfigurację, przenieś ścieżkę certyfikatu z RootCertFile do CertFile, a RootCertFile pozostaw dla urzędu certyfikacji, względem którego weryfikowana jest druga strona. Błąd jest celowo krytyczny. Bez niego klient po cichu przedstawiałby wygenerowany certyfikat samopodpisany, o innym odcisku przy każdym uruchomieniu.
VerifyCertificate jest teraz egzekwowane. Wcześniej wynik weryfikacji był obliczany, a następnie odrzucany, więc przy włączonej weryfikacji akceptowany był dowolny certyfikat, w tym wystawiony przez niezaufany urząd. Łańcuch, który nie przechodzi weryfikacji, przerywa teraz uzgadnianie. VerifyCertificate nadal ma domyślnie wartość False, więc domyślna konfiguracja pozostaje bez zmian.
Nie dotyczy to TsgcRTCPeerConnection. WebRTC uwierzytelnia drugą stronę na podstawie odcisku przenoszonego w SDP, a nie na podstawie łańcucha certyfikatów, i pozostawia VerifyCertificate wyłączone. Jest to normalna konfiguracja WebRTC i działa dokładnie tak jak dotychczas.
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;