TsgcUDPCLient › Propiedades › DTLSOptions
Configuración de certificado, verificación y OpenSSL aplicada cuando DTLS está habilitado.
property DTLSOptions: TsgcUDPDTLSClient_Options read FDTLSOptions write SetDTLSOptions;—
Agrupa los parámetros que controlan el protocolo de enlace DTLS. RootCertFile es el almacén de confianza utilizado para verificar al otro extremo, el mismo significado que tiene esta propiedad en los transportes TLS y QUIC. CertFile es el certificado de este cliente y lee un archivo que contiene el certificado junto con sus intermedios, por lo que un archivo de cadena funciona. KeyFile es la clave privada que acompaña a CertFile. VerifyCertificate activa o desactiva la validación del certificado del servidor y VerifyDepth limita la longitud de la cadena de certificados. Cuando VerifyCertificate es True y RootCertFile está vacío, se utiliza como ancla de confianza el almacén de certificados del sistema operativo. OpenSSL_Options selecciona la versión de la API OpenSSL (oslAPI_1_1 u oslAPI_3_0) y la carpeta desde la que se cargan las bibliotecas OpenSSL. Estos ajustes solo tienen efecto cuando DTLS es True y se ignoran para el tráfico UDP sin cifrar.
IOHandler (predeterminado iohOpenSSL) selecciona el motor DTLS. iohNativeTLS ejecuta el protocolo de enlace y los registros sobre el motor DTLS 1.2 nativo del paquete sgcCrypto, sin cargar ninguna biblioteca OpenSSL. Solo admite los conjuntos de cifrado ECDHE AEAD (AES-128-GCM, AES-256-GCM y ChaCha20-Poly1305) con certificados ECDSA o RSA sobre X25519, P-256 o P-384, requiere Extended Master Secret y no reanuda sesiones. CertFile y KeyFile pueden ser PEM o DER. Iniciar con iohNativeTLS en una compilación sin el paquete sgcCrypto genera un error. Cualquier otro valor conserva la ruta de OpenSSL. OnDTLSVerifyPeer no se dispara en la ruta nativa, porque no hay ningún objeto de certificado de OpenSSL que pasar. Cuando VerifyCertificate es True, la cadena se comprueba frente a RootCertFile o las raíces del sistema, y TsgcDTLS_Component, el motor DTLS que hay detrás de este componente, dispara en su lugar su evento OnVerifyPeerNative, con la cadena del par en DER (hoja primero), el veredicto y un var Accept. Vea SSL sin OpenSSL.
RootCertFile ha cambiado de significado, y este es un cambio incompatible. Antes se cargaba como el certificado de este extremo, lo que resultaba incoherente con el resto de la biblioteca. Una configuración que indica un certificado en RootCertFile y una clave en KeyFile dejando CertFile vacío genera ahora un error al iniciarse el 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.
Para actualizar una configuración así, traslade la ruta del certificado de RootCertFile a CertFile y deje RootCertFile para la autoridad de certificación con la que se verifica al otro extremo. El error es deliberadamente fatal. Sin él, el cliente presentaría de forma silenciosa un certificado autofirmado generado con una huella digital distinta en cada ejecución.
VerifyCertificate ahora se aplica. Anteriormente, el resultado de la verificación se calculaba y luego se descartaba, por lo que con la verificación habilitada se aceptaba cualquier certificado, incluido uno emitido por una autoridad no confiable. Una cadena que falla termina ahora el protocolo de enlace. VerifyCertificate sigue siendo False de forma predeterminada, así que la configuración predeterminada no cambia.
TsgcRTCPeerConnection no se ve afectado. WebRTC autentica al otro extremo mediante la huella digital transportada en el SDP, no mediante una cadena de certificados, y deja VerifyCertificate deshabilitado. Esa es la configuración WebRTC habitual y sigue funcionando exactamente igual que 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;