0Pricing
Security+ Academy · Lección

Casos de uso de PKI: HTTPS, S/MIME y firma de código

Aplique conceptos de PKI a situaciones reales: proteger el tráfico web, cifrar el correo electrónico con S/MIME y verificar la integridad del software mediante certificados de firma de código.

Casos de uso de PKI: HTTPS, S/MIME y firma de código es una lección gratuita de Security+ Academy en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Security+ Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Security+ Academy incluye 4 lecciones en total.

PKI en aplicaciones del mundo real

La infraestructura de clave pública (PKI) es la base invisible de las comunicaciones digitales seguras. Los certificados y las CA que ha estudiado se aplican a diario en docenas de escenarios reales. El examen Security+ evalúa su capacidad para reconocer casos de uso de PKI, comprender qué tipo de certificado es adecuado para cada uno e identificar qué protección proporciona PKI en cada contexto. Los tres casos de uso más importantes del examen son HTTPS/TLS (seguridad web), S/MIME (seguridad del correo electrónico) y la firma de código (integridad del software).

HTTPS: PKI para la seguridad web

HTTPS (HTTP sobre TLS) es el caso de uso más visible de PKI. Cuando se conecta a https://bank.com, su navegador: (1) recibe el certificado TLS del servidor, (2) verifica que la cadena de certificados conduce a una CA raíz de confianza, (3) comprueba el nombre de host con los campos SAN, (4) verifica que el certificado no esté revocado y (5) utiliza la clave pública para un intercambio de claves Diffie-Hellman con el fin de establecer una sesión cifrada. El icono del candado en el navegador indica que todas estas comprobaciones se realizaron correctamente. Un certificado ausente o no válido genera una advertencia del navegador que impide que la mayoría de los usuarios continúe.

# Check HTTPS certificate details
curl -v https://example.com 2>&1 | grep -A 10 'SSL certificate'

# Test TLS configuration quality
openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | \
  grep -E 'Protocol|Cipher|Verify'
# Protocol: TLSv1.3
# Cipher: TLS_AES_256_GCM_SHA384
# Verify return code: 0 (ok)

S/MIME: PKI para la seguridad del correo electrónico

S/MIME (Secure/Multipurpose Internet Mail Extensions) utiliza certificados PKI para proporcionar dos servicios de seguridad al correo electrónico. Cifrado: el remitente cifra el cuerpo del correo con la clave pública del destinatario, de modo que solo este pueda descifrarlo, lo que protege la confidencialidad incluso si el correo es interceptado durante el tránsito o se almacena en un servidor comprometido. Firmas digitales: el remitente firma con su clave privada, demostrando al destinatario que el correo procede realmente del remitente y no ha sido alterado, lo que protege la integridad y proporciona no repudio. S/MIME requiere que cada usuario tenga su propio certificado emitido por una CA.

# S/MIME email signing and encryption with OpenSSL
# Sign an email
openssl smime -sign -in email_body.txt -signer alice_cert.pem \
  -inkey alice_private.key -out signed_email.eml -outform PEM

# Encrypt an email (using Bob's public key/certificate)
openssl smime -encrypt -aes256 -in email_body.txt \
  -out encrypted_email.eml bob_cert.pem

# Bob decrypts with his private key
openssl smime -decrypt -in encrypted_email.eml \
  -recip bob_cert.pem -inkey bob_private.key

Firma de código: PKI para la integridad del software

La firma de código utiliza PKI para firmar digitalmente software —ejecutables, scripts, controladores e instaladores—, de modo que los usuarios puedan verificar que procede de un editor de confianza y no ha sido manipulado. El proveedor de software firma el código con una clave privada asociada a un certificado de firma de código emitido por una CA de confianza. Cuando un usuario ejecuta el software, el sistema operativo verifica la firma mediante la clave pública del proveedor presente en la cadena de certificados. Windows SmartScreen, macOS Gatekeeper y las tiendas de aplicaciones de iOS/Android dependen de la firma de código para establecer la procedencia del software. El software sin firmar puede bloquearse o activar advertencias de seguridad.

# Verify code signing on Windows (PowerShell)
Get-AuthenticodeSignature -FilePath 'C:\Software\installer.exe' | Format-List
# Status: Valid
# SignerCertificate: [certificate details]
# TimeStamperCertificate: [timestamp CA details]

# On Linux/macOS, verify GPG signature of downloaded software
gpg --verify hashicorp_public.gpg terraform.zip.sig terraform.zip
# Good signature from 'HashiCorp Security (hashicorp.com/security)'

Autenticación mediante certificado de cliente

La autenticación mediante certificado de cliente (también llamada TLS mutuo o mTLS) amplía el modelo TLS estándar al exigir que el cliente también presente un certificado. En TLS estándar, solo el servidor se autentica mediante un certificado; en mTLS, ambas partes se autentican mutuamente. Se utiliza para: autenticación de VPN (tarjetas inteligentes o certificados de cliente en lugar de contraseñas), autenticación de API (autenticación entre máquinas en la que el cliente es un servicio, no una persona) y acceso de administradores con privilegios (exigir que los administradores utilicen tokens de hardware con certificados integrados).

# nginx configuration for mutual TLS (client certificate required)
# server {
#   listen 443 ssl;
#   ssl_certificate /path/to/server_cert.pem;
#   ssl_certificate_key /path/to/server_key.pem;
#   ssl_client_certificate /path/to/ca_cert.pem;
#   ssl_verify_client on;
#   ssl_verify_depth 2;
# }

# Test with a client certificate
curl --cert client_cert.pem --key client_key.pem https://api.example.com/

Verificación de la clave de host de SSH

SSH utiliza criptografía de clave pública con dos fines: autenticación del servidor y autenticación del cliente. Autenticación del servidor: cuando se conecta por primera vez a un servidor SSH, este presenta su clave de host (clave pública). Su cliente SSH la almacena en ~/.ssh/known_hosts. En conexiones posteriores, si la clave de host cambia —lo que podría indicar un ataque MITM o la reinstalación del servidor—, SSH le avisa. Autenticación del cliente: en lugar de contraseñas, los administradores utilizan pares de claves; la clave pública se añade a authorized_keys del servidor y la clave privada (que nunca se envía) demuestra la identidad. Las claves de host de SSH son independientes de los certificados PKI, pero cumplen la misma función de confianza.

# First-time SSH connection stores server host key
ssh user@server.example.com
# The authenticity of host 'server.example.com' can't be established.
# ED25519 key fingerprint is SHA256:abc123...
# Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

# Host key stored in: ~/.ssh/known_hosts
cat ~/.ssh/known_hosts | grep server.example.com

# If host key changes: 
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

Firma y sellado de tiempo de documentos

PKI permite la firma digital de documentos con validez legal en muchas jurisdicciones. Las firmas de documentos PDF de Adobe, DocuSign y los sistemas gubernamentales de firma electrónica utilizan certificados PKI para firmar documentos. Un complemento fundamental de la firma de documentos es el sellado de tiempo: una Autoridad de Sellado de Tiempo de Confianza (TSA) firma también el hash del documento con una hora de confianza, demostrando que el documento existía en un momento específico. El sellado de tiempo también es esencial para la firma de código: sin una marca de tiempo, las firmas de código dejan de ser válidas cuando caduca el certificado de firma, incluso en el caso de software distribuido antes de su caducidad.

Certificados para dispositivos IoT

A medida que proliferan los dispositivos IoT, PKI proporciona un mecanismo para autenticar dispositivos a gran escala. Cada dispositivo recibe un certificado único durante su fabricación (un proceso denominado aprovisionamiento de identidad del dispositivo), lo que permite a los servidores autenticar dispositivos individuales mediante sus certificados. Esto permite escenarios como un contador inteligente que demuestra su identidad al servidor de la compañía eléctrica, un dispositivo médico que se autentica en la red de un hospital o una flota de vehículos que se autentica en el backend del fabricante. La PKI para IoT debe gestionar millones de dispositivos con recursos limitados, lo que impulsa la adopción de certificados ECC por su reducido tamaño y rápida verificación.

Autenticación de VPN con certificados

La autenticación de VPN basada en certificados es considerablemente más segura que la autenticación de VPN basada en contraseñas. Cada usuario o dispositivo de VPN recibe un certificado de cliente emitido por la CA interna de la organización. Al conectarse, la puerta de enlace VPN verifica el certificado de cliente, asegurándose de que lo haya emitido la CA interna de confianza, de que se encuentre dentro de su periodo de validez y de que no se haya revocado mediante CRL/OCSP. Cuando un empleado abandona la organización, revocar su certificado impide inmediatamente el acceso a la VPN, lo que es más fiable que confiar en que no haya compartido su contraseña con otras personas.

# OpenVPN client certificate configuration
# client
# remote vpn.example.com 1194
# proto udp
# ca ca.crt        <- CA certificate (trust anchor)
# cert client.crt  <- Client's certificate
# key client.key   <- Client's private key
# tls-auth ta.key 1
# cipher AES-256-GCM

# The VPN server verifies the client cert chain against ca.crt
# Revoked certs listed in CRL won't be accepted

Errores habituales relacionados con certificados

Los profesionales de la seguridad deben saber diagnosticar errores habituales de certificados. Certificado caducado: ha pasado la fecha notAfter; renueve el certificado. Desajuste de nombre de host: el SAN del certificado no coincide con el nombre de host solicitado; verifique los CN y SAN, ya que puede necesitar un certificado wildcard o con varios SAN. Certificado autofirmado: ninguna CA respalda este certificado; añádalo al almacén de confianza local o sustitúyalo por un certificado firmado por una CA. Cadena incompleta: el servidor no proporciona el certificado de la CA intermedia; configure el servidor para que envíe la cadena completa. Certificado revocado: la CRL o OCSP muestra la revocación; se requiere una respuesta inmediata ante un posible compromiso de la clave.

# Diagnose certificate errors with openssl
openssl s_client -connect server.example.com:443 2>&1
# Common error messages:
# depth=0 ... error 10 at 0 depth lookup: certificate has expired
# depth=0 ... error 18: self-signed certificate
# depth=0 ... error 20: unable to get local issuer certificate (broken chain)
# depth=0 ... error 23: certificate revoked
# Verify return code: 0 (ok) = success

Certificados wildcard frente a certificados SAN

Dos tipos de certificados permiten gestionar varios nombres de host. Un certificado wildcard cubre todos los subdominios de primer nivel de un dominio: *.example.com cubre www.example.com, mail.example.com y api.example.com, pero NO cubre sub.api.example.com (dos niveles). Un certificado y una clave privada para todos los servicios: es práctico, pero arriesgado si la clave se ve comprometida, ya que todos los servicios resultan afectados. Un certificado con varios SAN incluye explícitamente varios dominios específicos en la extensión SAN (por ejemplo, example.com, www.example.com y api.example.com). Es más granular, pero requiere actualizar el certificado cuando se añaden nuevos dominios.

Comprobación rápida

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

Repaso de la lección

En esta lección ha aprendido que HTTPS/TLS utiliza certificados de servidor para cifrar el tráfico web y autenticar servidores; los certificados S/MIME permiten firmar y cifrar correos electrónicos; los certificados de firma de código demuestran la integridad del software y la identidad del editor; y los certificados de cliente permiten la autenticación mutua en VPN y API. A continuación, exploraremos las políticas de contraseñas y la autenticación multifactor.

Preguntas frecuentes

¿La lección «Casos de uso de PKI: HTTPS, S/MIME y firma de código» es gratis?

Sí — el texto completo de «Casos de uso de PKI: HTTPS, S/MIME y firma de código» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Security+ Academy, actualiza a CoddyKit PRO. El curso de Security+ Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Casos de uso de PKI: HTTPS, S/MIME y firma de código»?

Aplique conceptos de PKI a situaciones reales: proteger el tráfico web, cifrar el correo electrónico con S/MIME y verificar la integridad del software mediante certificados de firma de código. Practicas Security+ Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Security+ Academy?

No se requiere experiencia previa. Security+ Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.

¿Cuánto tiempo toma la lección «Casos de uso de PKI: HTTPS, S/MIME y firma de código»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Security+ Academy?

Sí. Cada lección de Security+ Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Autoridades de certificación y cadenas de confianza
  2. Estructura de los certificados X.509
  3. Ciclo de vida y revocación de certificados
  4. Casos de uso de PKI: HTTPS, S/MIME y firma de código
← Volver a Security+ Academy