[{"data":1,"prerenderedAt":1806},["ShallowReactive",2],{"sc:header-data-es":3,"sc:footer-data-es":101,"glossary-posts-es":142,"content-es-list-c077398beed29":1805},{"lang":4,"home":5,"navigation":14,"contact":95},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/scepman/scepman-logo-all-white.svg","/products/scepman/scepman-logo-rgb.svg",{"es":10},{"title":11,"url":12,"alt":13},"Home","/es","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"es":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"es":22},{"title":23,"url":24},"Precios","/es/pricing",{"name":26,"languages":27},"partner",{"es":28},{"title":29,"url":30},"Partners","/es/partner",{"name":32,"languages":33,"children":36},"support-hub",{"es":34},{"title":35},"Support Hub",[37,53,68],{"name":38,"children":39},"support-hub-group-1",[40,47],{"name":41,"target":42,"languages":43},"docs","_blank",{"es":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"es":50},{"title":51,"url":52},"FAQ","/es/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"es":59},{"title":60,"url":61},"Support Ticket","https://support.scepman.com/support/tickets/new?ticket_form=technical_support_request_%28scepman%29",{"name":63,"target":42,"languages":64},"drop-a-question",{"es":65},{"title":66,"url":67},"Drop a Question","https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29",{"name":69,"children":70},"support-hub-group-3",[71,77],{"name":72,"languages":73},"glossary",{"es":74},{"title":75,"url":76},"Glosario","/es/glossary",{"name":78,"languages":79},"blog",{"es":80},{"title":81,"url":82},"Blog","/es/blog",{"name":84,"languages":85},"events",{"es":86},{"title":87,"url":88},"Eventos","/es/events",{"name":90,"languages":91},"about",{"es":92},{"title":93,"url":94},"Acerca de nosotros","/es/about-us",{"name":96,"languages":97},"contact",{"es":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksEs":132},"sales@SCEPman.com",[105],{"img":106,"alt":107,"url":108},"/products/scepman/scepman-logo-yellow.svg","SCEPman Logo","/",[110,114,118],{"icon":111,"url":112,"title":113},"fa-x-twitter","https://twitter.com/scepman_","X",{"icon":115,"url":116,"title":117},"fa-youtube","https://www.youtube.com/channel/UCKnLYxlQFhzdXkDADV_Unrg","Youtube",{"icon":119,"url":120,"title":121},"fa-linkedin","https://www.linkedin.com/showcase/scepman","LinkedIn",[123,126,129],{"title":124,"url":125,"target":42},"Privacy","https://www.glueckkanja.com/en/privacy",{"title":127,"url":128,"target":42},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":130,"url":131,"target":42},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[133,136,139],{"title":134,"url":135,"target":42},"Privacidad","https://www.glueckkanja.com/es/privacy",{"title":137,"url":138,"target":42},"Imprimir","https://www.glueckkanja.com/es/imprint",{"title":140,"url":141,"target":42},"Contacto y ubicaciones","https://www.glueckkanja.com/es/company/contact-and-locations",[143,481,855,1114,1350],{"id":144,"title":145,"author":146,"body":147,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":464,"moment":146,"navigation":476,"path":477,"seo":478,"stem":479,"tags":146,"webcast":462,"__hash__":480},"content_es/glossary/cryptography.md","Criptografía",null,{"type":148,"value":149,"toc":437},"minimal",[150,155,167,174,202,208,230,234,237,240,249,252,260,299,303,306,310,313,317,320,324,327,330,334,338,341,367,371,374,391,395,398,402,405,409,412,417],[151,152,154],"h2",{"id":153},"qué-dos-tipos-de-cifrado-basado-en-claves-existen","¿Qué dos tipos de cifrado basado en claves existen?",[156,157,158,159,163,164],"p",{},"Los dos tipos principales de cifrado basado en claves son el ",[160,161,162],"strong",{},"cifrado simétrico"," y el ",[160,165,166],{},"cifrado asimétrico.",[168,169,171],"h3",{"id":170},"cifrado-simétrico",[160,172,173],{},"Cifrado simétrico",[175,176,177,184,190,196],"ul",{},[178,179,180,183],"li",{},[160,181,182],{},"Uso de claves",": emplea una única clave tanto para cifrar como para descifrar.",[178,185,186,189],{},[160,187,188],{},"Velocidad",": en general, es más rápido y eficiente.",[178,191,192,195],{},[160,193,194],{},"Seguridad",": el principal reto consiste en compartir la clave entre las partes de forma segura.",[178,197,198,201],{},[160,199,200],{},"Ejemplos",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[168,203,205],{"id":204},"cifrado-asimétrico",[160,206,207],{},"Cifrado asimétrico",[175,209,210,215,220,225],{},[178,211,212,214],{},[160,213,182],{},": emplea un par de claves, una clave pública para cifrar y una clave privada para descifrar.",[178,216,217,219],{},[160,218,188],{},": más lento que el cifrado simétrico, porque los cálculos son más complejos.",[178,221,222,224],{},[160,223,194],{},": más seguro para distribuir claves, ya que la clave privada nunca se comparte.",[178,226,227,229],{},[160,228,200],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[168,231,233],{"id":232},"qué-tipo-de-cifrado-se-considera-más-seguro","¿Qué tipo de cifrado se considera más seguro?",[156,235,236],{},"Ambos esquemas se consideran seguros en el sentido de que, con un algoritmo actual y una longitud de clave suficiente, ningún ordenador de hoy puede romper el cifrado.",[156,238,239],{},"Qué tipo de cifrado resulta mejor depende del caso de uso, pero muchos escenarios exigen cifrado asimétrico, porque emplea un par de claves, una clave pública para cifrar y una clave privada para descifrar. La clave privada se mantiene en secreto, lo que refuerza la seguridad porque nunca hace falta compartirla.",[168,241,243,244],{"id":242},"qué-tipo-de-cifrado-es-mejor-para-grandes-volúmenes-de-datos","¿Qué tipo de cifrado es mejor para grandes volúmenes de datos? ",[245,246],"a",{"href":247,"id":248},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[156,250,251],{},"El cifrado simétrico, porque es más rápido.",[168,253,255,256],{"id":254},"cuál-es-el-proceso-general-del-cifrado-híbrido","¿Cuál es el proceso general del cifrado híbrido? ",[245,257],{"href":258,"id":259},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[261,262,263,269,275,281,287,293],"ol",{},[178,264,265,268],{},[160,266,267],{},"Generación de la clave",": el emisor genera una clave simétrica nueva (también llamada clave de sesión) para cifrar el mensaje propiamente dicho.",[178,270,271,274],{},[160,272,273],{},"Cifrado del mensaje",": el emisor usa la clave simétrica para cifrar el mensaje en texto claro y obtiene un texto cifrado.",[178,276,277,280],{},[160,278,279],{},"Cifrado de la clave",": a continuación, el emisor cifra la clave simétrica con la clave pública del destinatario (cifrado asimétrico).",[178,282,283,286],{},[160,284,285],{},"Transmisión",": el emisor envía al destinatario tanto el mensaje cifrado (el texto cifrado) como la clave simétrica cifrada.",[178,288,289,292],{},[160,290,291],{},"Descifrado de la clave",": el destinatario usa su clave privada para descifrar la clave simétrica.",[178,294,295,298],{},[160,296,297],{},"Descifrado del mensaje",": por último, el destinatario usa la clave simétrica descifrada para descifrar el texto cifrado y recuperar el texto claro original.",[151,300,302],{"id":301},"algoritmos-de-hash","Algoritmos de hash",[156,304,305],{},"Un algoritmo de hash es una función matemática que convierte datos de entrada de cualquier tamaño en una cadena de caracteres de longitud fija, normalmente una secuencia de letras y números. Esa salida se conoce como valor hash o resumen.",[168,307,309],{"id":308},"qué-es-una-colisión","¿Qué es una colisión?",[156,311,312],{},"En hashing, una colisión se produce cuando dos datos distintos generan el mismo valor hash con un algoritmo de hash. Esto resulta problemático porque el objetivo principal de un algoritmo de hash es representar de forma unívoca cada entrada de datos.",[168,314,316],{"id":315},"qué-es-un-mac","¿Qué es un MAC?",[156,318,319],{},"Código de autenticación de mensajes (MAC): en criptografía, un MAC es una pequeña porción de información que sirve para autenticar un mensaje y garantizar su integridad. Verifica que el mensaje no se ha alterado y confirma la identidad del emisor.",[168,321,323],{"id":322},"en-qué-se-diferencia-un-mac-de-un-hmac","¿En qué se diferencia un MAC de un HMAC?",[156,325,326],{},"MAC: término general para un código que verifica la integridad y la autenticidad de un mensaje mediante cifrados de bloque o funciones hash.",[156,328,329],{},"HMAC: un tipo concreto de MAC que utiliza una función hash criptográfica y una clave secreta, y que ofrece propiedades de seguridad más sólidas.",[151,331,333],{"id":332},"criptografía-asimétrica","Criptografía asimétrica",[168,335,337],{"id":336},"cuál-es-el-proceso-general-para-firmar-un-mensaje","¿Cuál es el proceso general para firmar un mensaje?",[156,339,340],{},"La firma de mensajes es un proceso criptográfico que sirve para verificar la autenticidad y la integridad de un mensaje.",[261,342,343,349,355,361],{},[178,344,345,348],{},[160,346,347],{},"Creación del hash:"," el emisor genera una huella digital única (un hash) del mensaje mediante una función hash criptográfica (por ejemplo, SHA-256). Ese hash representa de forma unívoca el contenido del mensaje.",[178,350,351,354],{},[160,352,353],{},"Firma:"," el emisor cifra ese hash con su clave privada y obtiene así la firma digital. De este modo, la firma solo puede generarla alguien que tenga acceso a la clave privada del emisor.",[178,356,357,360],{},[160,358,359],{},"Envío:"," la firma digital se adjunta al mensaje y ambos se envían al destinatario. También se facilita la clave pública del emisor para la verificación.",[178,362,363,366],{},[160,364,365],{},"Verificación:"," el destinatario usa la clave pública del emisor para descifrar la firma digital y recuperar el hash original. Después calcula un hash nuevo a partir del mensaje recibido y lo compara con el hash descifrado. Si coinciden, queda confirmado que el mensaje no se ha alterado y se verifica la identidad del emisor.",[168,368,370],{"id":369},"cuáles-son-las-tres-funciones-del-cifrado-asimétrico","¿Cuáles son las tres funciones del cifrado asimétrico?",[156,372,373],{},"El cifrado asimétrico, también conocido como criptografía de clave pública, cumple varias funciones importantes a la hora de proteger las comunicaciones y los datos.",[261,375,376,381,386],{},[178,377,378],{},[160,379,380],{},"Cifrado y descifrado",[178,382,383],{},[160,384,385],{},"Firmas digitales",[178,387,388],{},[160,389,390],{},"Intercambio de claves",[168,392,394],{"id":393},"rsa","RSA",[156,396,397],{},"RSA, abreviatura de Rivest-Shamir-Adleman, es un criptosistema de clave pública muy extendido para la transmisión segura de datos. Debe su nombre a sus inventores, Ronald Rivest, Adi Shamir y Leonard Adleman, que lo presentaron en 1977.",[168,399,401],{"id":400},"diffie-hellman","Diffie-Hellman",[156,403,404],{},"El intercambio de claves Diffie-Hellman es un método criptográfico que permite intercambiar claves criptográficas de forma segura a través de un canal público. Lo desarrollaron Whitfield Diffie y Martin Hellman en 1976. Su finalidad principal es que dos partes puedan generar de forma segura una clave secreta compartida con la que cifrar las comunicaciones posteriores.",[168,406,408],{"id":407},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[156,410,411],{},"El Digital Signature Algorithm (DSA) es un algoritmo criptográfico de clave pública que sirve para generar y verificar firmas digitales. Lo propuso el National Institute of Standards and Technology (NIST) en 1991 como parte del Digital Signature Standard (DSS).",[413,414,416],"h4",{"id":415},"cómo-funciona","Cómo funciona",[261,418,419,425,431],{},[178,420,421,424],{},[160,422,423],{},"Generación de claves:"," DSA genera un par de claves, una clave privada para firmar y una clave pública para verificar.",[178,426,427,430],{},[160,428,429],{},"Firma",": el emisor usa su clave privada para crear una firma digital sobre un mensaje. Esa firma es única para el mensaje y para la clave privada.",[178,432,433,436],{},[160,434,435],{},"Verificación",": el destinatario usa la clave pública del emisor para verificar la autenticidad de la firma y, por tanto, la integridad y el origen del mensaje.",{"title":438,"searchDepth":439,"depth":439,"links":440},"",2,[441,449,454],{"id":153,"depth":439,"text":154,"children":442},[443,445,446,447,448],{"id":170,"depth":444,"text":173},3,{"id":204,"depth":444,"text":207},{"id":232,"depth":444,"text":233},{"id":242,"depth":444,"text":243},{"id":254,"depth":444,"text":255},{"id":301,"depth":439,"text":302,"children":450},[451,452,453],{"id":308,"depth":444,"text":309},{"id":315,"depth":444,"text":316},{"id":322,"depth":444,"text":323},{"id":332,"depth":439,"text":333,"children":455},[456,457,458,459,460],{"id":336,"depth":444,"text":337},{"id":369,"depth":444,"text":370},{"id":393,"depth":444,"text":394},{"id":400,"depth":444,"text":401},{"id":407,"depth":444,"text":408},"md",false,"post",{"lang":465,"titleClass":466,"blogtitlepic":467,"socialimg":468,"customExcerpt":469,"asideNav":470,"maxContent":476},"es","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","El principal reto en el enrollment de certificados es cómo autenticar el dispositivo o el usuario que solicita el certificado. Con el certificado, la CA confirma que su titular tiene determinadas propiedades y que ha comprobado su autenticidad",{"menuItems":471},[472,474],{"href":473,"text":302},"#algoritmos-de-hash",{"href":475,"text":333},"#criptografía-asimétrica",true,"/glossary/cryptography",{"title":145,"description":438},"glossary/cryptography","GgBToIFBKTQZnsitHcTKmSiLzMT4vIttY6VMnXl9ZRs",{"id":482,"title":483,"author":146,"body":484,"cta":146,"description":488,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":839,"moment":146,"navigation":476,"path":851,"seo":852,"stem":853,"tags":146,"webcast":462,"__hash__":854},"content_es/glossary/enrollment-methods.md","Métodos de enrollment",{"type":148,"value":485,"toc":826},[486,489,492,495,524,614,616,620,630,634,652,655,658,662,665,668,691,695,698,701,714,718,721,724,727,730,733,736,745,748,752,756,759,765,769,778,781,784,787,804,816,819,822],[156,487,488],{},"Por tanto, una propiedad esencial de los protocolos de enrollment de certificados es cómo autentican a quien solicita el certificado. Según para qué se use el certificado, resultará más ventajoso un protocolo u otro.",[156,490,491],{},"Otra propiedad importante es su adopción real. Tanto la CA como el lado cliente deben admitir el método o el protocolo de enrollment para el caso de uso previsto.",[156,493,494],{},"Los protocolos de enrollment más habituales son:",[175,496,497,503,506,509,515,518,521],{},[178,498,499],{},[245,500,502],{"href":501},"scep","SCEP",[178,504,505],{},"ACME",[178,507,508],{},"EST",[178,510,511],{},[245,512,514],{"href":513},"microsoft-rpc-dcom","RPC/DCOM de Microsoft",[178,516,517],{},"SOAP de Microsoft",[178,519,520],{},"Enrollment manual en la página web de la CA",[178,522,523],{},"Otros protocolos propietarios",[525,526,527,528],"table",{},"\n    ",[529,530,531,527,553,534,574,527,594],"tbody",{},[532,533,534,535,534,538,534,541,534,544,534,547,534,550,527],"tr",{},"\n        ",[536,537],"th",{},[536,539,540],{},"DCOM y RPC propietarios de Microsoft",[536,542,543],{},"WS-Trust Enrollment Extension SOAP Enrollment",[536,545,546],{},"Automatic Certificate Management Environment (ACME)",[536,548,549],{},"Simple Certificate Enrollment Protocol (SCEP)",[536,551,552],{},"Enrollment over Secure Transport (EST)",[532,554,534,555,534,559,534,562,534,565,534,568,534,571,527],{},[556,557,558],"td",{},"Especificaciones",[556,560,561],{},"Microsoft OpenSpec1",[556,563,564],{},"Microsoft OpenSpec2",[556,566,567],{},"RFC 8555",[556,569,570],{},"Informal, ahora RFC 8894",[556,572,573],{},"RFC 7030 (+ …)",[532,575,534,576,534,579,534,582,534,585,534,588,534,591,527],{},[556,577,578],{},"Implementación",[556,580,581],{},"Lado servidor: Active Directory CS Lado cliente: Windows",[556,583,584],{},"Lado servidor: ADCS, ¿otros?  Lado cliente: Windows",[556,586,587],{},"Lado servidor: Let’s Encrypt Lado cliente: muchos",[556,589,590],{},"Muchas implementaciones de servidor y de cliente",[556,592,593],{},"Adopción escasa",[532,595,534,596,534,599,534,602,534,605,534,608,534,611,527],{},[556,597,598],{},"Autenticación",[556,600,601],{},"Autenticación de AD",[556,603,604],{},"Autenticación de AD\\* (formalmente, el usuario y la contraseña podrían no estar en AD)",[556,606,607],{},"Autenticación DNS",[556,609,610],{},"“SCEP Challenge”",[556,612,613],{},"CBA o autenticación HTTP Basic/Digest",[151,615,502],{"id":501},[168,617,619],{"id":618},"historia-y-especificación","Historia y especificación",[156,621,622,623,629],{},"El Simple Certificate Enrollment Protocol (SCEP) lo inventó Cisco. Aunque entonces no existía ningún estándar, se adoptó de forma masiva en los sistemas MDM. Cisco llegó incluso a diseñar un protocolo sucesor, Enrollment over Secure Transport (EST), para sustituir a SCEP. Por eso EST se convirtió en estándar público en el RFC 7030 mucho antes que SCEP, que se estandarizó en el ",[245,624,628],{"href":625,"rel":626},"https://www.rfc-editor.org/rfc/rfc8894.html",[627],"nofollow","RFC 8894"," bastante más tarde, cuando ya era el estándar de facto para el enrollment de certificados en sistemas MDM.",[168,631,633],{"id":632},"tecnología","Tecnología",[156,635,636,637,641,642,646,647,651],{},"SCEP se basa en HTTP. Una SCEP Request es un ",[245,638,640],{"href":639},"important-data-formats#pkcs7","PKCS#7"," cifrado y firmado que se envía al servicio SCEP mediante una petición GET o POST. El servicio responde con una SCEP Response, de nuevo un PKCS#7 cifrado y firmado. La petición contiene una solicitud de firma de certificado ",[245,643,645],{"href":644},"important-data-formats#pkcs10","PKCS#10"," y la respuesta contiene el ",[245,648,650],{"href":649},"important-data-formats#x509","certificado X.509"," emitido.",[168,653,598],{"id":654},"autenticación",[156,656,657],{},"La petición PKCS#10 contiene un \"SCEP Challenge\" que autentica y autoriza la solicitud de firma mediante algún método fuera de banda, según cuál sea el servicio SCEP concreto. Hoy se usan en la práctica tres tipos de SCEP Challenge:",[413,659,661],{"id":660},"scep-challenge-estático","SCEP Challenge estático",[156,663,664],{},"La posibilidad más sencilla es una contraseña estática. Si el SCEP Challenge del PKCS#10 coincide con un valor predefinido almacenado en el servicio SCEP, el certificado se emite; en caso contrario, la solicitud se rechaza. El problema de este método es que apenas permite comprobar si las propiedades solicitadas del certificado se corresponden con quien lo pide. De hecho, existe un CVE para este problema.",[156,666,667],{},"Estos métodos se pueden diferenciar aún más:",[261,669,670,678,685],{},[178,671,672,673,677],{},"En un enrollment SCEP ",[674,675,676],"em",{},"directo",", la entidad para la que se va a emitir el certificado se comunica directamente con el servicio SCEP. Por ejemplo, un sistema MDM indica a un teléfono Android que realice un enrollment SCEP usando el SCEP Challenge \"SecurePassword\". El teléfono Android genera una CSR, con suerte con los valores correctos, y añade \"SecurePassword\" como SCEP Challenge. Después envía la CSR al servicio SCEP y recibe a cambio el certificado emitido.",[178,679,680,681,684],{},"Un ",[674,682,683],{},"proxy SCEP transparente"," funciona igual que un proxy inverso HTTP. Como SCEP va cifrado y firmado, no puede examinar las peticiones ni las respuestas SCEP, y tampoco modificarlas, pero sí puede controlar quién solicita certificados y cuándo, en función de los perímetros de red.",[178,686,680,687,690],{},[674,688,689],{},"proxy SCEP adaptador de protocolo"," es un sistema que solicita certificados mediante SCEP en nombre de otro sistema. Por ejemplo, un sistema MDM como JAMF podría solicitar un certificado a un servicio SCEP en nombre de algún iPhone. Una vez que tiene el certificado y la clave privada, puede desplegar el certificado mediante otro protocolo. Así, solo el sistema MDM tiene acceso al SCEP Challenge y además puede controlar el contenido del certificado.",[413,692,694],{"id":693},"scep-challenge-dinámico","SCEP Challenge dinámico",[156,696,697],{},"En este caso, cada SCEP Challenge solo es válido para una única solicitud de certificado. Esto permite al servicio SCEP identificar la petición SCEP y verificar que las propiedades del certificado solicitado coinciden con las permitidas para esa solicitud concreta.",[156,699,700],{},"En la práctica hay dos formas habituales de que un sistema MDM y una CA con SCEP acuerden el SCEP Challenge que se usará en una solicitud:",[261,702,703,711],{},[178,704,705,706],{},"El sistema MDM solicita al servicio SCEP un código de un solo uso para una SCEP Request cuando lo necesita.\n",[261,707,708],{},[178,709,710],{},"Un ejemplo es Microsoft NDES. NDES dispone de una página de \"admin\" independiente que se autentica con credenciales de AD. Cada vez que se accede a esa página, se crea y se muestra un nuevo código de un solo uso que sirve para una única petición SCEP. En esta configuración, sin embargo, NDES no comprueba ninguna propiedad del certificado, porque el código de un solo uso es genérico.",[178,712,713],{},"El sistema MDM genera un código de un solo uso cuando indica a un sistema gestionado que solicite un certificado por SCEP. Cuando la SCEP Request llega al servicio SCEP, el servicio debe obtener el código de un solo uso del sistema MDM, normalmente mediante un web hook, y comprobar si coincide con el SCEP Challenge de la petición. No existe ningún estándar para este protocolo, así que el sistema MDM y el servicio SCEP tienen que acordar algún formato, y depende de la implementación que se compruebe alguna propiedad de la solicitud.",[413,715,717],{"id":716},"metadatos-firmados","Metadatos firmados",[156,719,720],{},"Prácticamente no hay límite de longitud para el SCEP Challenge. No tiene por qué ser una \"contraseña\" legible para una persona, también puede ser un BLOB.",[156,722,723],{},"Intune utiliza como SCEP Challenge un XML firmado y cifrado. Crea ese XML en el servidor y lo envía al dispositivo cliente cuando quiere emitir un certificado y crear la SCEP Request.",[156,725,726],{},"El servicio SCEP debe enviar la petición PKCS#10 completa a un servicio de SCEP Challenge de Intune. El servicio de SCEP Challenge tiene la clave privada para descifrar el XML y la clave pública para comprobar que lo creó un servicio de Intune legítimo.",[156,728,729],{},"El XML contiene metadatos sobre la solicitud, como el aspecto que debe tener el Subject. Esto se deriva, por un lado, del perfil de configuración de SCEP y, por otro, de los datos concretos del objeto del usuario o del dispositivo para el que se va a emitir el certificado.",[156,731,732],{},"Por ejemplo, el perfil de configuración de SCEP podría configurar CN={{DeviceId}} como subject. Cuando el dispositivo con el id xyz solicita un certificado, el XML indica entonces que el subject debe ser CN=xyz. El servicio de SCEP Challenge compara la información del XML con el subject de la petición PKCS#10. La validación fallará si los subjects difieren y será correcta si este y el resto de propiedades coinciden.",[156,734,735],{},"El servicio SCEP solo emitirá el certificado si la validación es correcta.",[156,737,738,739,744],{},"Microsoft publica ",[245,740,743],{"href":741,"rel":742},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[627],"un artículo"," en el que explica esta verificación.",[156,746,747],{},"Microsoft NDES lo admite con un módulo de directivas adicional de NDES; otras CA con SCEP pueden admitirlo de forma nativa o no.",[151,749,751],{"id":750},"microsoft-rpcdcom","Microsoft RPC/DCOM",[168,753,755],{"id":754},"historia","Historia",[156,757,758],{},"Los Microsoft Active Directory Certificate Services (ADCS), a veces llamados simplemente \"CA de Microsoft\", son el software de autoridad de certificación integrado en Windows Server. El software se desarrolló originalmente a finales del milenio pasado y siguió recibiendo algunas incorporaciones durante los diez o quince años siguientes.",[156,760,761,762,764],{},"Una alternativa es el SOAP de Microsoft o ",[245,763,502],{"href":501},", a los que Microsoft llama Web Enrollment y NDES, respectivamente.",[168,766,768],{"id":767},"especificación-y-adopción","Especificación y adopción",[156,770,771,772,777],{},"No nos consta que otros sistemas de CA implementen este protocolo, aunque entretanto Microsoft ha publicado ",[245,773,776],{"href":774,"rel":775},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[627],"la especificación en Microsoft OpenSpec",". En el lado cliente, Windows admite el protocolo de forma nativa; el resto de plataformas no están soportadas.",[168,779,633],{"id":780},"tecnología-1",[156,782,783],{},"Su método principal de enrollment es un protocolo propietario basado en RPC o DCOM.",[156,785,786],{},"El autoenrollment también utiliza este protocolo. Para que el autoenrollment funcione hacen falta",[175,788,789,792,795,798,801],{},[178,790,791],{},"un dispositivo unido al dominio.",[178,793,794],{},"una directiva de grupo que habilite el autoenrollment,",[178,796,797],{},"una CA de empresa (a diferencia de una CA independiente)",[178,799,800],{},"que emita una plantilla de certificado para la que",[178,802,803],{},"el usuario o el dispositivo tengan los permisos de enrollment y autoenrollment.",[156,805,806,807,811,812,815],{},"El intervalo predeterminado para comprobar si hay autoenrollments es de 8 horas, aunque se puede forzar con ",[808,809,810],"code",{},"certutil -pulse"," o, a menudo mejor, con ",[808,813,814],{},"gpupdate -force",".",[168,817,598],{"id":818},"autenticación-1",[156,820,821],{},"Este protocolo usa los protocolos de autenticación integrados en Active Directory, es decir, los usuarios y los equipos se autentican con sus credenciales de AD.",[823,824,825],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":438,"searchDepth":439,"depth":439,"links":827},[828,833],{"id":501,"depth":439,"text":502,"children":829},[830,831,832],{"id":618,"depth":444,"text":619},{"id":632,"depth":444,"text":633},{"id":654,"depth":444,"text":598},{"id":750,"depth":439,"text":751,"children":834},[835,836,837,838],{"id":754,"depth":444,"text":755},{"id":767,"depth":444,"text":768},{"id":780,"depth":444,"text":633},{"id":818,"depth":444,"text":598},{"lang":465,"seoTitle":840,"titleClass":466,"socialimg":841,"blogtitlepic":842,"customExcerpt":843,"keywords":844,"asideNav":845,"maxContent":476},"Métodos de enrollment de certificados: SCEP, ACME, EST y Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Cómo funciona el enrollment de certificados con SCEP, ACME, EST, Microsoft RPC y los métodos manuales. Comparativa de los protocolos de enrollment de PKI para una emisión segura de certificados.","métodos de enrollment de certificados, SCEP, ACME, EST, Microsoft RPC, protocolo de enrollment de certificados, enrollment de certificados en PKI, inscripción de certificados, enrollment over secure transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, enrollment de certificados de Microsoft",{"menuItems":846},[847,849],{"href":848,"text":502},"#scep",{"href":850,"text":751},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":483,"description":488},"glossary/enrollment-methods","vRYLjfo1mvZrJSS8Ms0KWl7kvKHMgVDRw8DYhiWKBaw",{"id":856,"title":857,"author":146,"body":858,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1092,"moment":146,"navigation":476,"path":1110,"seo":1111,"stem":1112,"tags":146,"webcast":462,"__hash__":1113},"content_es/glossary/important-data-formats.md","Formatos de datos importantes",{"type":148,"value":859,"toc":1075},[860,864,883,890,893,897,901,904,907,910,914,917,921,924,927,935,938,942,949,952,955,958,969,973,986,990,993,996,999,1002,1010,1014,1017,1020,1023,1034,1038,1041,1045,1054,1058,1066,1069],[151,861,863],{"id":862},"x509","X.509",[156,865,866,867,870,871,876,877,882],{},"X.509 es ",[674,868,869],{},"el"," estándar de los certificados digitales. Hubo competidores como ",[245,872,875],{"href":873,"rel":874},"https://www.rfc-editor.org/rfc/rfc4880",[627],"OpenPGP",", pero hoy se usan mucho menos. Aunque, un momento ... X.509 no es en realidad el estándar correcto. X.509 es un estándar de la ITU-T, mientras que las definiciones que de verdad importan forman parte del ",[245,878,881],{"href":879,"rel":880},"https://www.rfc-editor.org/rfc/rfc5280",[627],"RFC 5280",", es decir, de un estándar del IETF y no de la ITU-T. Ese RFC define el \"perfil de PKI para internet\" basado en X.509, pero es el único perfil que cuenta en la práctica.",[156,884,885,886,889],{},"Un certificado digital recurre a la criptografía asimétrica y, en especial, a las firmas digitales. Hoy el caso de uso más frecuente de los certificados digitales es la autenticación de servidores. Todo el mundo los ha usado ya, probablemente casi siempre sin saber que se trataba de un certificado X.509: cada vez que se accede a un sitio web HTTP",[160,887,888],{},"S",", el navegador establece una conexión TLS con el servidor web. El servidor web utiliza un certificado X.509 para demostrar quién es. Por ejemplo, cuando alguien accede al sitio web de su banco para transferir dinero desde su cuenta, quiere tener la certeza de que se está comunicando realmente con su banco. Un atacante podría intentar suplantar el sitio web del banco, leer la contraseña y el TAN del usuario y transferir después el dinero a una cuenta que él controla. HTTPS ayuda a evitarlo, porque los atacantes no disponen del certificado X.509 del servidor web del banco. Cuando el navegador indica que se está accediendo a un dominio concreto y que la conexión es HTTPS, el certificado garantiza que la conexión es realmente con un servidor web de alguien que posee ese dominio.",[156,891,892],{},"¿Cómo lo consigue el certificado? El certificado contiene ciertos metadatos, la clave pública de un par de claves criptográficas y una firma de una autoridad de certificación. Veamos esas tres partes:",[168,894,896],{"id":895},"contenido-de-un-certificado-x509","Contenido de un certificado X.509",[413,898,900],{"id":899},"metadatos","Metadatos",[156,902,903],{},"Los metadatos del certificado X.509 indican, entre otras cosas, durante qué periodo es válido, para qué debe usarse el certificado y a quién se emitió. En particular, en un certificado de servidor TLS contienen el dominio del servidor web. El navegador compara el dominio al que ha intentado acceder con el del certificado. Si no coinciden, el navegador no continúa y muestra una advertencia. Si el certificado ha caducado, también muestra una advertencia.",[156,905,906],{},"Curiosamente, los navegadores a menudo no mostraban ninguna advertencia al acceder a un sitio HTTP sin TLS, aunque eso es todavía menos seguro. Si se accedía a un servidor web con un certificado X.509 no válido, podía tratarse simplemente de un error de configuración y la conexión podía estar igualmente a salvo de atacantes que espiaran la comunicación, mientras que una conexión HTTP no ofrece protección alguna.",[156,908,909],{},"En cualquier caso, hay avances en este terreno, por ejemplo el certificate pinning. Pero ese es un tema avanzado, así que veamos los otros dos elementos presentes en un certificado X.509.",[413,911,913],{"id":912},"clave-pública","Clave pública",[156,915,916],{},"El certificado contiene la parte pública de un par de claves asimétricas. La criptografía permite al servidor web (o, en general, al titular del certificado si el caso de uso es otro) demostrar que también posee la parte privada del par de claves sin exponerla al cliente que se conecta ni a nadie más. Así, el cliente puede estar seguro de que el servidor web es realmente el propietario del certificado y no alguien que simplemente lo ha copiado. Copiar el certificado en sí es bastante fácil, ya que el servidor web envía una copia a todo el que intenta conectarse. Robar la clave privada es difícil o imposible, porque nunca sale del servidor web. Existen varios métodos para dificultar aún más el robo de la clave privada, como los HSM y los TPM.",[413,918,920],{"id":919},"firma-de-una-autoridad-de-certificación","Firma de una autoridad de certificación",[156,922,923],{},"Los metadatos permiten al cliente comprobar que el certificado es adecuado para el caso de uso concreto. La clave pública demuestra que la otra parte es realmente el propietario del certificado. Pero un atacante podría crear sin más un par de claves nuevo y un certificado nuevo que cumplieran también esos dos criterios. ¿Cómo sabría el cliente que el certificado es de fiar?",[156,925,926],{},"El certificado contiene una firma criptográfica de otro par de claves que pertenece al certificado de una autoridad de certificación (CA). El certificado de la CA se puede comprobar del mismo modo y también está firmado por un certificado. El cliente puede seguir esta \"cadena de confianza\" desde el certificado final, llamado certificado hoja, hasta el certificado de la CA raíz, que reconoce porque está autofirmado, es decir, la firma del certificado procede de su propio par de claves. Normalmente solo hay uno o dos pasos, así que solo intervienen uno o dos certificados de CA.",[156,928,929,930,934],{},"Las CA deben comprobar con cuidado que los metadatos son correctos cuando ",[245,931,933],{"href":932},"enrollment-methods/","emiten un certificado",". Por ejemplo, si se quiere un certificado de servidor TLS para un dominio propio, hay que demostrar a la CA que se es realmente su propietario. Según lo exhaustiva que sea esa comprobación, se obtiene un certificado básico o de validación extendida (EV).",[156,936,937],{},"Cada navegador y cada sistema operativo incluyen una lista de CA raíz de confianza predefinidas. Los usuarios o los administradores pueden añadir más CA raíz de confianza. Algunas CA raíz gozan de confianza solo para fines concretos, otras tienen una confianza más general. El cliente comprueba si la cadena de confianza termina en una CA raíz de confianza. Si es así, y si todos los certificados de la cadena siguen siendo válidos y los metadatos indican que se usan conforme a su finalidad, el certificado hoja del servidor web se considera de confianza y se establece la conexión.",[168,939,941],{"id":940},"validez-de-los-certificados-x509","Validez de los certificados X.509",[156,943,944,945,815],{},"En los certificados X.509 todo gira en torno a la confianza que hay que establecer. Como ya se ha explicado, un criterio de confianza es que el certificado encadene hasta una CA raíz de confianza. Otro es que se encuentre dentro de su periodo de validez. Eso suele significar que no ha caducado, pero, por lo general debido a errores técnicos, un certificado podría no ser válido todavía. Y hay un criterio más: la CA que emitió el certificado no debe haberlo revocado. Como es un tema en sí mismo, le dedicamos un ",[245,946,948],{"href":947},"other-stuff/certificate-lifecycle-management","artículo aparte",[151,950,640],{"id":951},"pkcs7",[156,953,954],{},"PKCS#7 es la navaja suiza de los formatos de datos criptográficos y puede contener prácticamente cualquier cosa: mensajes cifrados, mensajes firmados, mensajes firmados y cifrados, certificados y claves privadas",[156,956,957],{},"Esa es también la gran desventaja del formato. Cuando una aplicación o un usuario reciben un PKCS#7, no queda claro de entrada qué hacer con él. Estos son algunos casos de uso importantes:",[175,959,960,963,966],{},[178,961,962],{},"Los mensajes S/MIME son, básicamente, correos con cuerpos o adjuntos PKCS#7.",[178,964,965],{},"Las peticiones y las respuestas SCEP son, en realidad, mensajes PKCS#7 firmados.",[178,967,968],{},"Las respuestas EST son mensajes CMS.",[168,970,972],{"id":971},"codificación","Codificación",[156,974,975,976,980,981,985],{},"Las extensiones de archivo habituales son .p7b (",[245,977,979],{"href":978},"asn.1-and-pem#der-encoding","codificado en DER","), .p7s (un mensaje firmado o la firma de un mensaje) y .p7m (un mensaje firmado o cifrado, o ambas cosas). También está definida la ",[245,982,984],{"href":983},"asn.1-and-pem#pem-encoding","codificación PEM"," con la etiqueta \"PKCS7\", pero se usa poco.",[168,987,989],{"id":988},"herramientas","Herramientas",[156,991,992],{},"En Windows se pueden abrir los mensajes PKCS#7 con un doble clic y las extensiones de shell de criptografía los muestran. Sin embargo, normalmente solo se pueden extraer de ellos certificados y sus claves privadas, no el contenido de los mensajes.",[156,994,995],{},"Estos archivos se pueden convertir a otros formatos con herramientas como OpenSSL.",[151,997,645],{"id":998},"pkcs10",[156,1000,1001],{},"Una solicitud de firma de certificado (CSR) tal como la define PKCS#10 es un archivo que contiene la descripción de un certificado que se quiere obtener de una autoridad de certificación (CA). Su estructura es parecida a la de un certificado X.509, pero le falta la firma de una CA. En su lugar, contiene la firma de quien solicita el certificado. Aun así es un formato distinto, de modo que no equivale a un certificado autofirmado.",[156,1003,1004,1005,815],{},"Puede ir codificada en binario DER o en PEM ",[245,1006,1009],{"href":1007,"rel":1008},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[627],"con la etiqueta \"CERTIFICATE REQUEST\"",[151,1011,1013],{"id":1012},"pkcs12","PKCS#12",[156,1015,1016],{},"PKCS#12 también se conoce como PFX, sobre todo en entornos Windows. Por eso las extensiones de archivo habituales son .pfx y .p12. Contiene certificados X.509 y, casi siempre, las claves privadas correspondientes, aunque técnicamente no sea obligatorio.",[156,1018,1019],{},"Los datos de un archivo PKCS#12 suelen estar cifrados con contraseñas. A menudo solo se cifra la clave privada, de modo que se podrían extraer los certificados sin conocer las contraseñas si la aplicación lo permite (la mayoría no lo hace). En entornos Windows, PKCS#12 es la forma más habitual de guardar un certificado y su clave privada en un archivo. En entornos Linux son más frecuentes los archivos PKCS#8 con codificación PEM.",[156,1021,1022],{},"Como el estándar ofrece muchas opciones para almacenar certificados y claves privadas en \"safebags\" anidados, los archivos PKCS#12 presentan algunos problemas de compatibilidad, por ejemplo:",[175,1024,1025,1028,1031],{},[178,1026,1027],{},"Windows es conocido por asociar las claves privadas de un PKCS#12 a todos los certificados que se extraen del archivo, y no solo a aquel al que corresponden. Si el PKCS#12 contiene una cadena de certificados, Windows puede indicar que dispone de la clave privada del certificado de la CA.",[178,1029,1030],{},"En macOS no se pueden importar archivos PKCS#12 si los algoritmos criptográficos son demasiado recientes.",[178,1032,1033],{},"Puede ser necesario cifrar los certificados de un archivo PKCS#12 para que las aplicaciones receptoras puedan extraerlos. Pero algunas solo admiten algoritmos muy antiguos y débiles, lo que normalmente no supone un problema, ya que la información es pública de todos modos. OpenSSL 3.x, en cambio, no admite esos algoritmos antiguos y vulnerables y se niega a abrir el PKCS#12.",[151,1035,1037],{"id":1036},"asn1-y-pem","ASN.1 y PEM",[156,1039,1040],{},"La Abstract Syntax Notation One (ASN.1) es un lenguaje que sirve para describir estructuras de datos. Existen algunos tipos de datos básicos predefinidos, como los enteros o las secuencias, y el autor de un protocolo o de un formato de archivo puede definir a partir de ellos tipos de datos propios.",[168,1042,1044],{"id":1043},"codificación-der","Codificación DER",[156,1046,1047,1048,1053],{},"El ",[245,1049,1052],{"href":1050,"rel":1051},"https://www.itu.int/rec/T-REC-X.680/",[627],"estándar X.680 de la ITU-T"," define distintas codificaciones para los datos especificados en ASN.1. Para los datos relacionados con X.509, la codificación más importante es DER, porque solo hay una manera de codificar un tipo; por tanto, el hash de la representación binaria DER de ese tipo tendrá siempre el mismo valor, algo importante, por ejemplo, al firmar datos codificados en ASN.1.",[168,1055,1057],{"id":1056},"codificación-pem","Codificación PEM",[156,1059,1060,1061,1065],{},"Para muchos tipos de archivo relacionados con X.509, aunque no para todos, el archivo se puede guardar en binario con codificación DER o aplicar además una ",[245,1062,984],{"href":1063,"rel":1064},"https://datatracker.ietf.org/doc/html/rfc7468",[627]," sobre la codificación DER. PEM usa únicamente caracteres ASCII, así que se puede copiar y pegar con facilidad en el portapapeles o, hace unas décadas cuando esto todavía era relevante, enviar por correo electrónico.",[168,1067,989],{"id":1068},"herramientas-1",[156,1070,1071,1072,815],{},"Si se tiene un archivo codificado en ASN.1 y no se sabe de qué tipo es, o no hay ninguna aplicación que gestione ese tipo concreto, aún se puede decodificar la estructura ASN.1 en bruto y ver qué contiene. En Windows, la herramienta integrada certutil lo hace con el comando ",[808,1073,1074],{},"certutil -decode",{"title":438,"searchDepth":439,"depth":439,"links":1076},[1077,1081,1085,1086,1087],{"id":862,"depth":439,"text":863,"children":1078},[1079,1080],{"id":895,"depth":444,"text":896},{"id":940,"depth":444,"text":941},{"id":951,"depth":439,"text":640,"children":1082},[1083,1084],{"id":971,"depth":444,"text":972},{"id":988,"depth":444,"text":989},{"id":998,"depth":439,"text":645},{"id":1012,"depth":439,"text":1013},{"id":1036,"depth":439,"text":1037,"children":1088},[1089,1090,1091],{"id":1043,"depth":444,"text":1044},{"id":1056,"depth":444,"text":1057},{"id":1068,"depth":444,"text":989},{"lang":465,"seoTitle":1093,"titleClass":466,"blogtitlepic":1094,"socialimg":1095,"customExcerpt":1096,"keywords":1097,"asideNav":1098,"maxContent":476},"Formatos de datos importantes: X.509, PKCS, ASN.1 y PEM explicados","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Los formatos esenciales de criptografía y de certificados, entre ellos X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 y PEM.","formatos de datos importantes, certificado X.509, formatos PKCS, PKCS 7, PKCS 10, PKCS 12, ASN.1, formato PEM, certificados digitales, infraestructura de clave pública, formatos de PKI",{"menuItems":1099},[1100,1102,1104,1106,1108],{"href":1101,"text":863},"#x509",{"href":1103,"text":640},"#pkcs7",{"href":1105,"text":645},"#pkcs10",{"href":1107,"text":1013},"#pkcs12",{"href":1109,"text":1037},"#asn1-y-pem","/glossary/important-data-formats",{"title":857,"description":438},"glossary/important-data-formats","nmVVGqOJ1mTFHiMO3lfcRSRZMqUiJC5Ka57raP1owAc",{"id":1115,"title":1116,"author":146,"body":1117,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1340,"moment":146,"navigation":476,"path":1346,"seo":1347,"stem":1348,"tags":146,"webcast":462,"__hash__":1349},"content_es/glossary/public-key-infrastructure.md","Infraestructura de clave pública",{"type":148,"value":1118,"toc":1329},[1119,1123,1131,1134,1166,1170,1173,1177,1180,1210,1213,1217,1220,1240,1243,1247,1254,1268,1273,1287,1291,1296,1309,1314,1326],[151,1120,1122],{"id":1121},"establecer-la-confianza","Establecer la confianza",[168,1124,1126,1127,1130],{"id":1125},"cómo-indica-un-cliente-que-confía-en-una-ca-raíz-concreta","¿Cómo ",[160,1128,1129],{},"indica"," un cliente que confía en una CA raíz concreta?",[156,1132,1133],{},"Un cliente manifiesta su confianza en una determinada autoridad de certificación (CA) raíz mediante un proceso que se apoya en la cadena de confianza de los certificados. Así es como funciona:",[175,1135,1136,1142,1148,1154,1160],{},[178,1137,1138,1141],{},[160,1139,1140],{},"Certificados raíz preinstalados:"," la mayoría de los sistemas operativos y los navegadores web vienen con un conjunto de certificados raíz preinstalados de CA de confianza. Esos certificados raíz se guardan en un almacén de raíces de confianza.",[178,1143,1144,1147],{},[160,1145,1146],{},"Validación del certificado:"," cuando un cliente se conecta a un servidor (por ejemplo, al visitar un sitio web), el servidor presenta su certificado TLS. Ese certificado suele estar firmado por una CA intermedia que, a su vez, está firmada por una CA raíz.",[178,1149,1150,1153],{},[160,1151,1152],{},"Verificación de la cadena de confianza:"," el cliente verifica la cadena de confianza comprobando si el certificado presentado está firmado por una CA raíz de confianza. También comprueba si las CA intermedias de la cadena son de confianza.",[178,1155,1156,1159],{},[160,1157,1158],{},"Firmas digitales:"," cada certificado de la cadena está firmado digitalmente por la CA situada por encima. El cliente usa la clave pública de la CA para verificar esas firmas y asegurarse de que los certificados no se han manipulado.",[178,1161,1162,1165],{},[160,1163,1164],{},"Decisión de confianza:"," si toda la cadena de confianza es válida y termina en una CA raíz de confianza, el cliente confía en el certificado del servidor. Eso permite que la comunicación segura continúe.",[168,1167,1169],{"id":1168},"qué-ventaja-tienen-las-ca-intermedias-frente-a-una-única-ca-raíz","¿Qué ventaja tienen las CA intermedias frente a una única CA raíz?",[156,1171,1172],{},"En las PKI de infraestructura, una única raíz puede resultar ventajosa.",[168,1174,1176],{"id":1175},"cómo-obtiene-su-certificado-una-ca-intermedia","¿Cómo obtiene su certificado una CA intermedia?",[156,1178,1179],{},"Una autoridad de certificación (CA) intermedia obtiene su certificado mediante un proceso de firma por parte de una CA raíz, conocido como cross-signing. Así es como funciona:",[261,1181,1182,1188,1194,1199,1204],{},[178,1183,1184,1187],{},[160,1185,1186],{},"Solicitud de firma de certificado (CSR):"," la organización que quiere crear una CA intermedia genera una CSR. Esa CSR incluye la clave pública y la información identificativa de la CA intermedia.",[178,1189,1190,1193],{},[160,1191,1192],{},"Envío a la CA raíz:"," la CSR se envía a una CA raíz de confianza.",[178,1195,1196,1198],{},[160,1197,365],{}," la CA raíz verifica la identidad y la legitimidad de la organización que solicita el certificado intermedio.",[178,1200,1201,1203],{},[160,1202,353],{}," una vez verificada, la CA raíz usa su clave privada para firmar la CSR y crea así el certificado intermedio. Ese certificado firmado vincula la CA intermedia con la CA raíz y establece una cadena de confianza.",[178,1205,1206,1209],{},[160,1207,1208],{},"Emisión:"," la CA raíz emite el certificado intermedio firmado a la organización solicitante, que puede usarlo entonces para firmar certificados de entidad final (por ejemplo, certificados TLS para sitios web).",[156,1211,1212],{},"Este proceso garantiza que la CA intermedia sea de confianza en virtud de su vínculo con la CA raíz, en la que los navegadores y los sistemas operativos ya confían.",[168,1214,1216],{"id":1215},"qué-es-una-cadena-de-certificados-cómo-funciona","¿Qué es una cadena de certificados? ¿Cómo funciona?",[156,1218,1219],{},"Una cadena de certificados, también llamada cadena de confianza, es una secuencia de certificados que garantiza la autenticidad y la fiabilidad de un certificado digital. Así es como funciona:",[175,1221,1222,1228,1234],{},[178,1223,1224,1227],{},[160,1225,1226],{},"Proceso de verificación:"," cuando un cliente (por ejemplo, un navegador web) se conecta a un servidor, el servidor presenta su certificado de entidad final. El cliente comprueba entonces la cadena de certificados para asegurarse de que cada certificado está firmado por el siguiente de la cadena, hasta llegar al certificado raíz.",[178,1229,1230,1233],{},[160,1231,1232],{},"Cadena de confianza:"," cada certificado de la cadena se verifica con la clave pública del certificado que está por encima. El proceso continúa hasta el certificado raíz, en el que el cliente ya confía.",[178,1235,1236,1239],{},[160,1237,1238],{},"Establecimiento de la confianza:"," si toda la cadena es válida y termina en un certificado raíz de confianza, el cliente confía en el certificado de entidad final y la comunicación segura puede continuar.",[156,1241,1242],{},"Este sistema garantiza que el certificado de entidad final es legítimo y que lo ha emitido una autoridad de confianza, y mantiene así la integridad y la seguridad de las comunicaciones digitales.",[168,1244,1246],{"id":1245},"qué-problema-trata-de-resolver-la-extensión-basic-constraints","¿Qué problema trata de resolver la extensión Basic Constraints?",[156,1248,1249,1250,1253],{},"La extensión ",[160,1251,1252],{},"Basic Constraints"," de un certificado digital resuelve el problema de distinguir los distintos tipos de certificados y sus funciones dentro de una infraestructura de clave pública (PKI). Así es como funciona:",[175,1255,1256,1262],{},[178,1257,1258,1261],{},[160,1259,1260],{},"Identificación de la autoridad de certificación (CA):"," indica si un certificado es un certificado de CA o un certificado de entidad final. Esa distinción es crucial, porque los certificados de CA pueden emitir otros certificados y los de entidad final no.",[178,1263,1264,1267],{},[160,1265,1266],{},"Restricción de la longitud de la ruta:"," puede limitar el número de CA intermedias que pueden existir por debajo de esta CA en la cadena de certificados. Eso ayuda a evitar cadenas de certificados excesivamente largas, que pueden ser ineficientes y potencialmente inseguras.",[156,1269,1270],{},[160,1271,1272],{},"Problemas que resuelve:",[175,1274,1275,1281],{},[178,1276,1277,1280],{},[160,1278,1279],{},"Evitar la emisión no autorizada de certificados:"," al marcar con claridad qué certificados pueden actuar como CA, impide que los certificados de entidad final emitan otros certificados y mantiene así la integridad de la PKI.",[178,1282,1283,1286],{},[160,1284,1285],{},"Controlar la longitud de la cadena de certificados:"," limitar la longitud de la ruta garantiza que la cadena de certificados siga siendo manejable y segura, y evita las posibles vulnerabilidades asociadas a las cadenas largas",[168,1288,1290],{"id":1289},"qué-mecanismos-emplea-para-resolver-estos-problemas"," ¿Qué mecanismos emplea para resolver estos problemas?",[156,1292,1249,1293,1295],{},[160,1294,1252],{}," de un certificado digital utiliza los siguientes mecanismos para resolver los problemas de distinguir los certificados de CA de los de entidad final y de controlar la longitud de la cadena de certificados:",[175,1297,1298,1304],{},[178,1299,1300,1303],{},[160,1301,1302],{},"Indicador de CA:"," este indicador señala si el certificado es un certificado de autoridad de certificación (CA) o de entidad final. Si está en TRUE, el certificado puede usarse para firmar otros certificados, lo que significa que es un certificado de CA. Si está en FALSE, es un certificado de entidad final y no puede emitir otros certificados.",[178,1305,1306,1308],{},[160,1307,1266],{}," especifica el número máximo de certificados intermedios no autoemitidos que pueden seguir a este certificado en una ruta de certificación válida. Con esa restricción, la extensión limita la longitud de la cadena de certificados y garantiza que siga siendo manejable y segura.",[156,1310,1311],{},[160,1312,1313],{},"Cómo funcionan estos mecanismos:",[175,1315,1316,1321],{},[178,1317,1318,1320],{},[160,1319,1302],{}," cuando se emite un certificado, el indicador de CA se establece según el uso previsto del certificado. Durante el proceso de validación, los clientes comprueban este indicador para determinar si se puede confiar en el certificado para emitir otros certificados.",[178,1322,1323,1325],{},[160,1324,1266],{}," este valor se comprueba durante el proceso de validación para asegurar que la cadena de certificados no supera la longitud especificada. Si la cadena es demasiado larga, el certificado se considera no válido.",[156,1327,1328],{},"Estos mecanismos ayudan a mantener la integridad y la seguridad de la infraestructura de clave pública (PKI), ya que garantizan que solo los certificados autorizados puedan emitir otros certificados y evitan cadenas de certificados excesivamente largas.",{"title":438,"searchDepth":439,"depth":439,"links":1330},[1331],{"id":1121,"depth":439,"text":1122,"children":1332},[1333,1335,1336,1337,1338,1339],{"id":1125,"depth":444,"text":1334},"¿Cómo indica un cliente que confía en una CA raíz concreta?",{"id":1168,"depth":444,"text":1169},{"id":1175,"depth":444,"text":1176},{"id":1215,"depth":444,"text":1216},{"id":1245,"depth":444,"text":1246},{"id":1289,"depth":444,"text":1290},{"lang":465,"seoTitle":1341,"titleClass":466,"socialimg":1342,"blogtitlepic":1343,"customExcerpt":1344,"keywords":1345,"maxContent":476},"Establecer la confianza en una infraestructura de clave pública: modelo de confianza de los certificados PKI","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Cómo establecer la confianza en una PKI mediante cadenas de certificados, CA raíz e intermedias y una validación segura de los certificados.","establecer la confianza en una PKI, confianza en la infraestructura de clave pública, cadena de confianza de certificados, confianza en la CA raíz, confianza en la CA intermedia, modelo de confianza de PKI, validación de certificados, certificados raíz de confianza, verificación segura de certificados, verificación de la cadena de confianza","/glossary/public-key-infrastructure",{"title":1116,"description":438},"glossary/public-key-infrastructure","1A-Yr_oCT3hq28w2YPzosTI4OqIFPqa4EE5qH4s2eA8",{"id":1351,"title":1352,"author":146,"body":1353,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1795,"moment":146,"navigation":476,"path":1801,"seo":1802,"stem":1803,"tags":146,"webcast":462,"__hash__":1804},"content_es/glossary/use-cases-for-certificates.md","Casos de uso de los certificados",{"type":148,"value":1354,"toc":1780},[1355,1359,1363,1377,1381,1413,1417,1448,1452,1458,1464,1468,1521,1525,1529,1543,1547,1559,1563,1566,1580,1584,1591,1602,1607,1618,1624,1635,1639,1659,1663,1666,1671,1691,1696,1713,1718,1738,1742,1745,1777],[151,1356,1358],{"id":1357},"transport-layer-security-tls","Transport Layer Security (TLS)",[168,1360,1362],{"id":1361},"qué-dos-preguntas-debe-hacerse-un-cliente-al-recibir-un-certificado-de-un-servidor","¿Qué dos preguntas debe hacerse un cliente al recibir un certificado de un servidor?",[261,1364,1365,1371],{},[178,1366,1367,1370],{},[160,1368,1369],{},"¿El certificado es válido y de confianza?"," El cliente tiene que verificar que el certificado lo ha emitido una autoridad de certificación (CA) de confianza y que no ha caducado ni ha sido revocado. Para ello comprueba el periodo de validez del certificado y se asegura de que está firmado por una CA en la que confía.",[178,1372,1373,1376],{},[160,1374,1375],{},"¿El certificado se corresponde con la identidad del servidor?"," El cliente debe asegurarse de que los datos del certificado, como el Common Name (CN) o el Subject Alternative Name (SAN), coinciden con el nombre de dominio del servidor. Así se confirma que el certificado está realmente destinado al servidor al que el cliente intenta conectarse.",[168,1378,1380],{"id":1379},"cómo-valida-el-cliente-que-un-certificado-es-de-confianza","¿Cómo valida el cliente que un certificado es de confianza?",[261,1382,1383,1389,1395,1401,1407],{},[178,1384,1385,1388],{},[160,1386,1387],{},"Comprobar la cadena de confianza del certificado:"," el cliente verifica la cadena de certificados, que incluye el certificado del servidor, los certificados intermedios y el certificado raíz. Cada certificado de la cadena debe estar firmado por la autoridad inmediatamente superior, hasta llegar a un certificado raíz de confianza.",[178,1390,1391,1394],{},[160,1392,1393],{},"Verificar el periodo de validez del certificado:"," el cliente comprueba el periodo de validez del certificado para asegurarse de que no ha caducado ni empieza a ser válido más adelante. Para ello revisa las fechas “Not Before” y “Not After” del certificado.",[178,1396,1397,1400],{},[160,1398,1399],{},"Comparar el certificado con la identidad del servidor:"," el cliente se asegura de que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Eso confirma que el certificado está destinado al servidor al que se está conectando.",[178,1402,1403,1406],{},[160,1404,1405],{},"Comprobar la revocación:"," el cliente comprueba si el certificado ha sido revocado consultando la lista de revocación de certificados (CRL) o usando el Online Certificate Status Protocol (OCSP). Un certificado revocado deja de ser de confianza.",[178,1408,1409,1412],{},[160,1410,1411],{},"Verificar la firma digital:"," el cliente verifica la firma digital del certificado para asegurarse de que no se ha manipulado. Para ello comprueba la firma criptográfica con la clave pública de la CA emisora.",[168,1414,1416],{"id":1415},"cómo-valida-el-cliente-que-el-servidor-es-el-verdadero-propietario-de-un-certificado","¿Cómo valida el cliente que el servidor es el verdadero propietario de un certificado?",[261,1418,1419,1425,1431,1437,1443],{},[178,1420,1421,1424],{},[160,1422,1423],{},"Verificación de la cadena de certificados:"," el cliente verifica la cadena de certificados y comprueba que cada certificado de la cadena está firmado por una autoridad de certificación (CA) de confianza. Esa cadena empieza en el certificado del servidor y termina en un certificado raíz de confianza.",[178,1426,1427,1430],{},[160,1428,1429],{},"Coincidencia del nombre de dominio:"," el cliente comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Así se garantiza que el certificado está destinado al servidor al que se está conectando.",[178,1432,1433,1436],{},[160,1434,1435],{},"Verificación de la firma digital:"," el cliente verifica la firma digital del certificado con la clave pública de la CA emisora. Esto garantiza que el certificado no se ha manipulado y que lo ha emitido realmente una CA de confianza.",[178,1438,1439,1442],{},[160,1440,1441],{},"Periodo de validez del certificado:"," el cliente comprueba el periodo de validez del certificado para asegurarse de que es válido en ese momento y de que no ha caducado.",[178,1444,1445,1406],{},[160,1446,1447],{},"Comprobación del estado de revocación:",[168,1449,1451],{"id":1450},"por-qué-importa-la-propiedad-si-ya-se-ha-comprobado-que-el-certificado-es-de-confianza","¿Por qué importa la propiedad si ya se ha comprobado que el certificado es de confianza?",[156,1453,1454,1457],{},[160,1455,1456],{},"Validez y confianza del certificado:"," este paso garantiza que el certificado lo ha emitido una autoridad de certificación (CA) de confianza, que está dentro de su periodo de validez y que no ha sido revocado. Confirma que el certificado es legítimo y que no se ha manipulado.",[156,1459,1460,1463],{},[160,1461,1462],{},"Verificación de la identidad del servidor:"," aunque un certificado sea válido y de confianza, también hay que confirmar que pertenece al servidor al que uno se conecta. Para ello se comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. Este paso garantiza que el certificado está destinado a ese servidor concreto y evita los ataques de intermediario, en los que un atacante podría presentar un certificado válido de otro dominio.",[168,1465,1467],{"id":1466},"cuáles-son-los-dos-métodos-con-los-que-el-cliente-responde-a-esta-pregunta-qué-dos-resultados-se-producen-con-cada-uno","¿Cuáles son los dos métodos con los que el cliente responde a esta pregunta? ¿Qué dos resultados se producen con cada uno?",[261,1469,1470,1497],{},[178,1471,1472,1475,1476,1479,1482,1483],{},[160,1473,1474],{},"Verificación mediante el sistema de nombres de dominio (DNS):"," el cliente comprueba que el Common Name (CN) o el Subject Alternative Name (SAN) del certificado coincide con el nombre de dominio del servidor. ",[1477,1478],"br",{},[160,1480,1481],{},"Resultado",":",[175,1484,1485,1491],{},[178,1486,1487,1490],{},[160,1488,1489],{},"Coincidencia",": si los nombres coinciden, el cliente puede continuar con la conexión, con la seguridad de que el certificado está destinado a ese servidor. ",[178,1492,1493,1496],{},[160,1494,1495],{},"Discrepancia",": si los nombres no coinciden, lo más probable es que el cliente interrumpa la conexión o muestre una advertencia que señale un posible riesgo de seguridad.",[178,1498,1499,1502,1503,1505,1482,1507],{},[160,1500,1501],{},"Verificación mediante la infraestructura de clave pública (PKI):"," el cliente verifica la firma digital del certificado con la clave pública de la autoridad de certificación (CA) emisora. ",[1477,1504],{},[160,1506,1481],{},[175,1508,1509,1515],{},[178,1510,1511,1514],{},[160,1512,1513],{},"Firma válida",": si la firma es válida, queda confirmado que el certificado no se ha manipulado y que lo ha emitido una CA de confianza.",[178,1516,1517,1520],{},[160,1518,1519],{},"Firma no válida:"," si la firma no es válida, el cliente interrumpirá la conexión o mostrará una advertencia para indicar que el certificado puede estar comprometido o ser fraudulento.",[168,1522,1524],{"id":1523},"qué-determina-qué-método-se-utiliza","¿Qué determina qué método se utiliza?",[156,1526,1527],{},[160,1528,1474],{},[175,1530,1531,1537],{},[178,1532,1533,1536],{},[160,1534,1535],{},"Uso",": este método se aplica siempre como parte del handshake TLS. El cliente compara el Common Name (CN) o el Subject Alternative Name (SAN) del certificado con el nombre de dominio del servidor para comprobar que coinciden.",[178,1538,1539,1542],{},[160,1540,1541],{},"Factores determinantes:"," forma parte del protocolo TLS estándar y el cliente lo ejecuta de forma automática al establecer una conexión segura.",[156,1544,1545],{},[160,1546,1501],{},[175,1548,1549,1554],{},[178,1550,1551,1553],{},[160,1552,1535],{},": este método también se aplica siempre durante el handshake TLS. El cliente verifica la firma digital del certificado con la clave pública de la autoridad de certificación (CA) emisora.",[178,1555,1556,1558],{},[160,1557,1541],{}," es otra parte estándar del protocolo TLS. El cliente realiza esta comprobación automáticamente para asegurarse de que el certificado es válido y de que no se ha manipulado.",[151,1560,1562],{"id":1561},"qué-certificados-debe-enviar-el-servidor-al-cliente","¿Qué certificados debe enviar el servidor al cliente?",[156,1564,1565],{},"Durante el handshake TLS, el servidor debe enviar al cliente los siguientes certificados:",[175,1567,1568,1574],{},[178,1569,1570,1573],{},[160,1571,1572],{},"Certificado de entidad final:"," es el certificado propio del servidor, con el que demuestra su identidad ante el cliente.",[178,1575,1576,1579],{},[160,1577,1578],{},"Certificados intermedios:"," estos certificados enlazan el certificado de entidad final con el certificado raíz de confianza. Ayudan a establecer una cadena de confianza que va desde el certificado del servidor hasta un certificado raíz de confianza.",[151,1581,1583],{"id":1582},"qué-son-los-certificados-de-validación-de-dominio-y-de-validación-extendida","¿Qué son los certificados de validación de dominio y de validación extendida?",[156,1585,1586,1587,1590],{},"Los ",[160,1588,1589],{},"certificados de validación de dominio (DV)"," son un tipo de certificado TLS en el que la autoridad de certificación (CA) verifica que el solicitante controla el dominio. Normalmente se hace de estas formas:",[175,1592,1593,1596,1599],{},[178,1594,1595],{},"Respondiendo a un correo enviado al contacto administrativo del dominio.",[178,1597,1598],{},"Añadiendo un registro TXT en el DNS.",[178,1600,1601],{},"Subiendo un archivo al servidor web.",[156,1603,1604],{},[160,1605,1606],{},"Características principales:",[175,1608,1609,1612,1615],{},[178,1610,1611],{},"Emisión rápida: se pueden emitir con rapidez, a menudo en cuestión de minutos, porque requieren una validación mínima.",[178,1613,1614],{},"Seguridad básica: proporcionan cifrado y una garantía básica de que el dominio está bajo el control de quien solicita el certificado.",[178,1616,1617],{},"Buena relación coste-beneficio: suelen ser más baratos o incluso gratuitos, lo que los hace accesibles para sitios web pequeños y proyectos personales.",[156,1619,1586,1620,1623],{},[160,1621,1622],{},"certificados de validación extendida (EV)"," son un certificado TLS de nivel superior que exige un proceso de validación más riguroso. La CA verifica la existencia legal, física y operativa de la entidad que solicita el certificado. Esto incluye:",[175,1625,1626,1629,1632],{},[178,1627,1628],{},"Confirmar la identidad y la situación legal de la entidad.",[178,1630,1631],{},"Verificar su presencia física y operativa.",[178,1633,1634],{},"Asegurar que la entidad tiene derechos exclusivos de uso del dominio.",[156,1636,1637],{},[160,1638,1606],{},[175,1640,1641,1647,1653],{},[178,1642,1643,1646],{},[160,1644,1645],{},"Alto nivel de garantía:"," ofrece a los usuarios el máximo nivel de confianza y garantía, porque implica una comprobación exhaustiva.",[178,1648,1649,1652],{},[160,1650,1651],{},"Indicadores visibles:"," en algunos navegadores, los certificados EV mostraban el nombre de la organización en la barra de direcciones, aunque hoy es menos habitual.",[178,1654,1655,1658],{},[160,1656,1657],{},"Mayor confianza:"," idóneos para sitios web que manejan información sensible, como los de entidades financieras y de comercio electrónico.",[168,1660,1662],{"id":1661},"cuáles-son-más-seguros"," ¿Cuáles son más seguros?",[156,1664,1665],{},"Por lo general, los certificados de validación extendida (EV) se consideran más seguros que los de validación de dominio (DV), debido al riguroso proceso de validación al que se someten. Esta es la comparación:",[156,1667,1668],{},[160,1669,1670],{},"Certificados de validación de dominio (DV)",[175,1672,1673,1679,1685],{},[178,1674,1675,1678],{},[160,1676,1677],{},"Nivel de validación:"," solo verifica el control sobre el dominio.",[178,1680,1681,1684],{},[160,1682,1683],{},"Seguridad:"," proporciona cifrado y garantías básicas.",[178,1686,1687,1690],{},[160,1688,1689],{},"Caso de uso:"," adecuados para sitios web personales, blogs y pequeñas empresas.",[156,1692,1693],{},[160,1694,1695],{},"Certificados de validación extendida (EV)",[175,1697,1698,1703,1708],{},[178,1699,1700,1702],{},[160,1701,1677],{}," verifica la existencia legal, física y operativa de la entidad.",[178,1704,1705,1707],{},[160,1706,1683],{}," ofrece un mayor nivel de confianza y garantía gracias a la comprobación exhaustiva.",[178,1709,1710,1712],{},[160,1711,1689],{}," idóneos para entidades financieras, sitios de comercio electrónico y cualquier web que maneje información sensible.",[156,1714,1715],{},[160,1716,1717],{},"Por qué los certificados EV son más seguros:",[175,1719,1720,1726,1732],{},[178,1721,1722,1725],{},[160,1723,1724],{},"Comprobación exhaustiva:"," los certificados EV exigen una validación extensa, lo que dificulta que entidades maliciosas los obtengan.",[178,1727,1728,1731],{},[160,1729,1730],{},"Indicadores de confianza:"," aunque hoy es menos habitual, los certificados EV mostraban el nombre de la organización en la barra de direcciones del navegador y ofrecían así una garantía visible a los usuarios.",[178,1733,1734,1737],{},[160,1735,1736],{},"Mayor garantía:"," el proceso de verificación detallado confirma que la entidad que hay detrás del certificado es legítima, lo que reduce el riesgo de phishing y de otros ataques.",[151,1739,1741],{"id":1740},"cuál-es-el-proceso-de-revocación-con-ocsp-stapling","Cuál es el proceso de revocación con OCSP stapling",[156,1743,1744],{},"El OCSP stapling mejora el proceso OCSP estándar porque reduce la latencia y protege mejor la privacidad. Así es como funciona:",[261,1746,1747,1753,1759,1765,1771],{},[178,1748,1749,1752],{},[160,1750,1751],{},"El servidor solicita una respuesta OCSP:"," el servidor web consulta periódicamente el estado de revocación de su certificado al respondedor OCSP (un servidor que mantiene la autoridad de certificación, o CA). Esa consulta se hace en segundo plano y no en cada conexión de un cliente.",[178,1754,1755,1758],{},[160,1756,1757],{},"El respondedor OCSP devuelve una respuesta:"," el respondedor OCSP envía una respuesta OCSP firmada y con marca de tiempo que indica el estado del certificado (por ejemplo, “good”, “revoked” o “unknown”). El servidor guarda esa respuesta en caché.",[178,1760,1761,1764],{},[160,1762,1763],{},"Handshake TLS con la respuesta adjunta:"," cuando un cliente (por ejemplo, un navegador web) inicia una conexión con el servidor, el servidor incluye la respuesta OCSP en caché dentro del handshake TLS. Esto es lo que se conoce como “stapling” de la respuesta en el handshake.",[178,1766,1767,1770],{},[160,1768,1769],{},"El cliente verifica la respuesta OCSP:"," el cliente verifica la respuesta OCSP adjunta. Como la respuesta está firmada por la CA, el cliente puede fiarse de su validez. Si la respuesta indica que el certificado está revocado, el cliente no establecerá una conexión segura.",[178,1772,1773,1776],{},[160,1774,1775],{},"Actualizaciones periódicas:"," el servidor sigue actualizando periódicamente la respuesta OCSP en caché para disponer siempre de un estado actual que ofrecer durante el handshake TLS.",[156,1778,1779],{},"Este proceso reduce la necesidad de que los clientes hagan consultas OCSP por separado, lo que mejora el rendimiento y la privacidad.",{"title":438,"searchDepth":439,"depth":439,"links":1781},[1782,1790,1791,1794],{"id":1357,"depth":439,"text":1358,"children":1783},[1784,1785,1786,1787,1788,1789],{"id":1361,"depth":444,"text":1362},{"id":1379,"depth":444,"text":1380},{"id":1415,"depth":444,"text":1416},{"id":1450,"depth":444,"text":1451},{"id":1466,"depth":444,"text":1467},{"id":1523,"depth":444,"text":1524},{"id":1561,"depth":439,"text":1562},{"id":1582,"depth":439,"text":1583,"children":1792},[1793],{"id":1661,"depth":444,"text":1662},{"id":1740,"depth":439,"text":1741},{"lang":465,"seoTitle":1796,"titleClass":466,"socialimg":1797,"blogtitlepic":1798,"customExcerpt":1799,"keywords":1800,"maxContent":476},"Transport Layer Security (TLS): casos de uso y validación de certificados","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Los certificados TLS protegen el sitio web y a sus usuarios: verifican los servidores, generan confianza mediante cadenas de certificados y aseguran conexiones cifradas.","certificados TLS, Transport Layer Security, casos de uso de los certificados, validación de certificados TLS, cadena de confianza de certificados, certificados DV, certificados EV, autenticación de servidores, conexiones seguras, OCSP stapling","/glossary/use-cases-for-certificates",{"title":1352,"description":438},"glossary/use-cases-for-certificates","cmDfwUT8jWG9dHKv-rWZ8D8JaeeN7YcqEkhFA7JKUYA",{"list":142,"authors":146},1790098989902]