{"id":14907,"date":"2023-09-25T12:49:01","date_gmt":"2023-09-25T19:49:01","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14907"},"modified":"2023-10-18T03:04:29","modified_gmt":"2023-10-18T10:04:29","slug":"securing-couchbase-with-tls-certificates-part-2","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/securing-couchbase-with-tls-certificates-part-2\/","title":{"rendered":"Asegurando la Comunicaci\u00f3n con Certificados TLS: Una gu\u00eda definitiva para Couchbase Server (Parte 2 de 3)"},"content":{"rendered":"

En la parte 1 de esta serie de 3 partes aprendimos sobre los componentes de TLS<\/a>En la parte 2 veremos c\u00f3mo interact\u00faan entre s\u00ed los componentes de TLS. En Parte 3<\/a> de esta gu\u00eda, veremos c\u00f3mo se utilizan los componentes en Couchbase Server.<\/span><\/p>\n

Proceso de firma de certificados<\/h2>\n

Tanto si gestiona su propia autoridad de certificaci\u00f3n interna como si recurre a un proveedor comercial establecido, como DigiCert, GlobalSign o GoDaddy, la primera etapa consiste en generar una solicitud de firma de certificado. Cada vez que un nuevo certificado o un certificado de reemplazo necesita ser emitido, la entidad que solicita el certificado genera un par de claves que consiste en una clave privada y una clave p\u00fablica ellos mismos, normalmente utilizando el paquete OpenSSL. En un Cluster de Servidores Couchbase la entidad ser\u00eda un Nodo de Servidor Couchbase individual. La entidad guarda la clave privada de forma segura, mientras que la clave p\u00fablica se incluye en una solicitud de firma de certificado (CSR) que se env\u00eda a la CA. Normalmente esto se realiza con una CA intermedia, no con una CA ra\u00edz.\u00a0<\/span><\/p>\n

\"\"<\/p>\n

Al recibir la CSR, la CA verifica la identidad de la entidad empleando diversos m\u00e9todos de validaci\u00f3n, como la validaci\u00f3n del dominio o la validaci\u00f3n de la organizaci\u00f3n. Una vez confirmada la identidad, la CA genera una firma digital utilizando su clave privada, que vincula la clave p\u00fablica de la entidad con su informaci\u00f3n de identidad. Este certificado firmado se devuelve a la entidad.<\/span><\/p>\n

Validaci\u00f3n de certificados<\/span><\/h2>\n

Para validar un certificado, la parte que conf\u00eda en \u00e9l (por ejemplo, un navegador web) debe asegurarse de que el certificado es aut\u00e9ntico y ha sido emitido por una CA de confianza. Este proceso implica una serie de pasos, que incluyen las cuatro etapas siguientes.<\/span><\/p>\n

Ancla de confianza<\/span><\/h3>\n

\"\"<\/h3>\n

La parte que conf\u00eda, por ejemplo un navegador web, posee un conjunto preinstalado de certificados ra\u00edz de confianza, tambi\u00e9n conocidos como anclas de confianza. Estos certificados pertenecen a CA conocidas y contienen sus claves p\u00fablicas, lo que sirve como base de la confianza.<\/span><\/p>\n

Cuando un cliente o servidor recibe un certificado durante el intercambio SSL\/TLS, comprueba si la firma digital del certificado puede ser validada por alguna de las anclas de confianza instaladas en el sistema. Si la cadena del certificado se puede rastrear hasta un anclaje de confianza, el certificado se considera aut\u00e9ntico y la conexi\u00f3n TLS prosigue con confianza.\u00a0<\/span><\/p>\n

Ruta de certificaci\u00f3n<\/span><\/h3>\n

\"\"<\/p>\n

Al establecer una conexi\u00f3n cifrada TLS, la parte que conf\u00eda (navegador web) examina la ruta de certificaci\u00f3n del certificado, que incluye una cadena de certificados que comienza con el certificado emitido y llega hasta un anclaje de confianza. Cada certificado de la cadena est\u00e1 firmado por el certificado subsiguiente, llegando finalmente a un anclaje de confianza.<\/span><\/p>\n

Verificaci\u00f3n de firmas<\/span><\/h3>\n

La parte que conf\u00eda (navegador web) utiliza la clave p\u00fablica de cada certificado de la ruta de certificaci\u00f3n para verificar la firma digital del siguiente certificado. Este proceso contin\u00faa hasta que se alcanza el anclaje de confianza.<\/span><\/p>\n

La firma digital es un valor criptogr\u00e1fico creado por la CA utilizando su clave privada, que vincula el contenido del certificado a la identidad de la CA. El cliente utiliza la clave p\u00fablica de la CA para descifrar la firma digital, y si el descifrado coincide con el contenido del certificado, la firma se considera v\u00e1lida. Esta validaci\u00f3n confirma que el certificado no ha sido manipulado y que ha sido emitido por la CA de confianza.\u00a0<\/span><\/p>\n

Controles de confianza y caducidad<\/span><\/h3>\n

La parte que conf\u00eda comprueba si el anclaje de confianza est\u00e1 incluido en sus certificados ra\u00edz de confianza preinstalados. Tambi\u00e9n comprueba la fecha de caducidad de cada certificado para asegurarse de que sigue siendo v\u00e1lido.<\/span><\/p>\n

\"\"<\/p>\n


\n<\/span>Si toda la ruta de certificaci\u00f3n se valida correctamente, y el ancla de confianza es de confianza, la parte que conf\u00eda considera que el certificado es genuino y procede con la conexi\u00f3n segura. Con Couchbase Server 7.2.x esta cadena puede tener 10 certificados de profundidad.<\/span><\/p>\n

En este ejemplo, las autoridades de certificaci\u00f3n ra\u00edz de confianza incorporadas en el navegador web son nombres inventados, pero puede consultar una lista real. Las CA de confianza preautorizadas de Firefox son enlazado desde su wiki<\/a><\/span>. Si su certificado ha sido generado por una CA que no ha sido emitida por una de las CA de confianza integradas, primero tendr\u00e1 que a\u00f1adir el certificado p\u00fablico de la CA como entidad de confianza a su sistema operativo y navegador antes de poder utilizar los certificados emitidos por esa CA.<\/span><\/p>\n

Ahora que hemos visto los componentes que intervienen en TLS y c\u00f3mo funcionan, en la parte 3 veremos c\u00f3mo funciona TLS en Couchbase Server<\/a>.<\/span><\/p>\n