Diferencias

Muestra las diferencias entre dos versiones de la página.

--- sad:t1:practica1 [2017/09/13 10:41]
José Manuel Guallar
+++ sad:t1:practica1 [2019/01/04 13:18]
@@ Línea 1: / Línea 1: @@
-====== PKI y CA ======
-  - Las **CA (Certification Authority)** son los servidores que se encargan de emitir los certificados que luego se utilizarán como medios de identificación
-  - La infraestructura de CAs de una organización se denomina **PKI (Public Key Infrastructure)**
-  - Cuando se crea una CA, el software genera automáticamente un certificado raíz autofirmado
-  * Es el certificado más importante de una CA
-  *    La clave privada de este certificado se utilizará para firmar cualquier otro certificado emitido por la CA
-  - En una PKI puede haber varias CA organizadas jerárquicamente pero que dependan de una única CA raíz
-====== Criterios de confianza de un certificado ======
-Para que el sistema operativo confíe en un certificado se tiene que cumplir:
-  * Que el sistema confíe en la CA que emitió el certificado
-  * Que el nombre que figura en el certificado coincida con el nombre del sistema o la dirección de correo electrónico u otro parámetro en función del tipo de certificado
-  * Que el certificado no esté caducado ni haya sido revocado
-====== Dos tipos de CA: públicas y privadas ======
-**CA pública**
-  * Son PKI gestionadas por empresas privadas o gubernamentales que emiten certificados públicos
-  * Los certificados de estas CA suelen venir instalados de serie en los sistemas operativos
-  * Suelen tener un proceso de registro muy exhaustivo
-  * La emisión del certificado tiene un coste económico
-**CA privada o interna**
-  * Es instalada por el administrador de sistemas para uso privado en su red
-  * Requiere que instalemos el certificado de la CA en todos los sistemas
-  * La emisión del certificado no tiene coste económico
-====== PKI y CA en WS2K8 ======
-En Windows Server 2008, una CA es un servidor con el rol “AD CS” instalado
-Una CA puede emitir certificados, revocarlos, publicar la lista de certificados revocados (CRL) o la lista de información AIA (Authority Information Access) para que los certificados emitidos a usuarios, sistemas o servicios puedan ser validados
-En las PKI de WS2K8 caben dos tipos de CA:
-**CA raíz**: dispone de certificado autofirmado y puede emitir certificados para otra CA
-**CA subordinada**: dispone de certificado firmado por otra CA raíz
-Pueden estar o no integradas en el Directorio Activo
-**CA Stand-alone**: no requiere Directorio Activo
-**CA Empresarial**: se integra en un Directorio Activo y exige que el servidor forme parte de un Dominio de
-Directorio Activo
-===== Recomendación de seguridad en una PKI jerárquica =====
-  * La CA raíz de la PKI se implementa como stand-alone
-  * Las CAs subordinadas de la PKI son certificadas por la CA raíz, pero se recomienda que sean de tipo empresarial (integradas en el Directorio Activo)
-  * Una vez creadas las Enterprise-CAs subordinadas, se desconecta la CA raíz de la red o directamente se apaga el servidor
-  - De este modo protegemos la clave privada de la CA raíz
-  - La CA raíz sólo se encenderá cuando haya que certificar una nueva CA subordinada
-====== Enunciado ======
-Trabajaremos con dos servidores WS2K8 Enterprise Edition (tienen un rol de PKI más completo que la versión Standard)
-La primera maquina se llamara **SRV-RootCA**seguido del numero de lista
-Servidor stand-alone donde se instalará la CA raíz
-El servidor está en un grupo de trabajo (GW-PKI)
-La segunda maquina se llama **DC1** en mi caso, en el vuestro las iniciales de vuestro nombre y apellidos
-Controlador de dominio del dominio **EMBOSA** en vuestro caso ASIR
-En él se instalará una CA subordinada e integrada en el Directorio Activo
-También se usarán los servicios web de este servidor como rutas para publicar los AIA (Authority Information Access) y los RDP (Revocation List Distribution Point) de las dos CAs
-Nota
-** Una vez instalada una CA en un servidor, éste ya yo puede cambiar de nombre**
-comprobación inicial de nombres NetBIOS
-{{:sad:t1:imagen1.png?400|}}
-Instalación de los servicios DS CA en SRV-RootCA
-{{:sad:t1:imagen2.png?400|}}
-{{:sad:t1:imagen3.png?400|}}
-Instalación de los servicios web para la inscripción de certificados, lo que requerirá IIS
-{{:sad:t1:imagen4.png?400|}}
-{{:sad:t1:imagen5.png?400|}}
-Comenzamos la configuración de la CA raiz (no está en dominio, sólo podemos elegir Independiente)
-{{:sad:t1:imagen6.png?400|}}
-Elegimos CA raiz
-{{:sad:t1:imagen7.png?400|}}
-Creamos una nueva clave privada
-{{:sad:t1:imagen8.png?400|}}
-Definimos del CSP (Proveedor de Servicios de Cifrado) que utilizamos
-{{:sad:t1:imagen9.png?400|}}
-Asignamos nombre a la CA raiz
-{{:sad:t1:imagen10.png?400|}}
-Establece el periodo de validez del certificado de la CA raíz autofirmado
-{{:sad:t1:imagen11.png?400|}}
-Definimos la ruta de la base de datos de certificados y del registro de emisión
-{{:sad:t1:imagen12.png?400|}}
-Configuración por defecto propuesta de la instalación de IIS
-{{:sad:t1:imagen13.png?400|}}
-Por seguridad, asegurar una copia de la clave privada de la CA raiz
-{{:sad:t1:imagen14.png?400|}}
-{{:sad:t1:imagen15.png?400|}}
-{{:sad:t1:imagen16.png?400|}}
-Obtención del certificado público de la CA raíz para la distribución: accedemos http://localhost/certsrv
-{{:sad:t1:imagen17.png?400|}}
-Descargamos el certificado de CA
-{{:sad:t1:imagen19.png?400|}}
-{{:sad:t1:imagen20.png?400|}}
-{{:sad:t1:imagen21.png?400|}}
-====== Instalación del certificado público de la CA raíz ======
-  * Debe instalarse en todos los sistemas que necesiten confiar en los certificados emitidos por la CA raíz y todas sus subordinadas
-  * En su instalación hay que incluirlo en el contenedor de Entidades de certificación raíz de confianza
-  * Puesto que finalmente se apagará la CA raíz habrá que publicar en algún servidor web las rutas de AIA (Authority Information Access) y CDP (o RDP o CRL, Certification-List Distribution Point)
-Deben configurarse las rutas de publicación antes de emitir ningún certificado ya que la información se incluye en los certificados emitidos
-===== Modificación de las rutas AIA y CDP (propiedades CD, pestaña Extension) =====
-  * Se agregan rutas para CDP y para AIA que apunten al servidor en que se publicarán
-  * Ejemplo de ruta: http://dc1.embosa.com/certenroll/<Nombre DNS del Servidor>_<Nombre de CA><Nombre del Certificado>.crt
-{{:sad:t1:imagen22.png?400|}}
-{{:sad:t1:imagen23.png?400|}}
-Hay que asegurarse de marcar las casillas inferiores de inclusión de certificados
-{{:sad:t1:imagen24.png?400|}}
-Añadimos el resto de rutas
-Ejemplo de ruta CDP:http://dc1.embosa.com/certenroll/<nombre de CA><Sufijo de nombre de lista CRL><Diferencias entre listas CRL permitidas>.crl
-{{:sad:t1:imagen25.png?400|}}
-Nos qudarán las siguitentes publicaciones
-{{:sad:t1:imagen26.png?400|}}
-===== Certificaciones Cruzadas =====
-Creación de una CA subordinada e integrada en el directorio activo
-Configuramos el DNS para que los sistemas puedan encontrarse por su FQDN
-{{:sad:t1:imagen27.png?400|}}
-Instalamos el rol de AD CS en el servidor sobre el que crearemos la CA subordinada
-{{:sad:t1:imagen28.png?400|}}
-Como el servidor está en el dominio podemos elegir "Empresa" y subordinada
-{{:sad:t1:imagen29.png?400|}}
-{{:sad:t1:imagen30.png?400|}}
-Generamos el certificados para esta nueva CA
-{{:sad:t1:imagen31.png?400|}}
-Elegimos la criptografía y el nombre para la nueva CA
-{{:sad:t1:imagen32.png?400|}}
-{{:sad:t1:imagen33.png?400|}}
-Solicitamos un certificado a la CA raíz
-Generamos una solicitud de certificado que luego usaremos para que sea firmado por la CA raíz
-Finalizamos el asistente
-{{:sad:t1:imagen34.png?400|}}
-Nos conectamos a http://srv-rootca/certsrv y solicitamos el certificado para la CA subordinada con solicitud avanzada
-{{:sad:t1:imagen35.png?400|}}
-{{:sad:t1:imagen36.png?400|}}
-Solicitamos el certificado desde el archivo con la petición que generamos anteriormente
-{{:sad:t1:imagen37.png?400|}}
-Se copia el contenido del fichero en el bloc de notas y lo pegamos en la pagina
-Se envia la solicitud
-{{:sad:t1:imagen38.png?400|}}
-Entonces se genera la solicitud, que queda pendiente en la CA raíz para que podamos aprobarla manualmente
-{{:sad:t1:imagen39.png?400|}}
-Seguidamente vamos a la CA raíz y aprobamos la solicitud de certificado de la CA subordinada
-{{:sad:t1:imagen40.png?400|}}
-{{:sad:t1:imagen41.png?400|}}
-Para utilizar el certificado es necesario confiar en la CA raíz
-Su certificado público debe estar en todos los sistemas que vayan a utilizar los certificados de ambas CA
-Se pueden distribuir mediante directivas de grupo del dominio
-{{:sad:t1:imagen42.png?400|}}
-{{:sad:t1:imagen43.png?400|}}
-Una vez importado, el directorio activo se encargará de distribuirlo a todos los sistemas del dominio
-{{:sad:t1:imagen44.png?400|}}
-Descargamos el certificado de la CA subordinada y repetimos el proceso con el certificado que dejamos sin terminar y que está pendiente
-{{:sad:t1:imagen45.png?400|}}
-{{:sad:t1:imagen46.png?400|}}
-Descargamos el certificado con la opción “Descargar cadena de Certificados”
-{{:sad:t1:imagen47.png?400|}}
-Habilitamos la CA subordinada utilizando este certificado con la opción “Instalar el certificado de CA”
-{{:sad:t1:imagen48.png?400|}}
-{{:sad:t1:imagen49.png?400|}}
-Ajuste de las rutas AIA y CPD de la CA subordinada
-{{:sad:t1:imagen50.png?400|}}
-===== OCSP =====
-**Instalación de un servidor OCSP (Online Certificate Status Protocol)**
-Los administradores de las CA pueden revocar los certificados
-Se deben publicar CRL (Certificate Revocation List) con los certificados revocados
-Las CRL pueden ser:
-  * CRL completa (listados completos)
-  * CRL delta (listas diferenciales)
-WS2K8 implementa el protocolo OCSP que sirve para consultar el estado de un certificado sin necesidad de descargar las listas CRL completas
-  * OCSP es un protocolo del tipo cliente-servidor
-  * En su funcionamiento se asemeja a un DNS, pero para certificados en vez de para direcciones IP
-Habilitar el servicio OCSP
-Habilitamos la ruta en donde se encontrará el servidor OCSP
-El servicio OCSP se identifica con un certificado específico de OCSP
-Localizamos en la lista de plantillas la plantilla de certificado “Firma de Respuesta de OCSP” y hacemos doble clic para acceder a sus propiedades. En la pestaña de Seguridad seleccionamos en la DACL a usuarios autentificados y le asignamos el permiso “Inscribirse”
-A continuación cerramos la consola de las plantillas de certificados y desde la herramienta de administración de la CA seleccionamos la plantilla que acabamos de modificar para que el servidor pueda usarla a la hora de generar certificados
-Haciendo clic con el botón derecho sobre Plantillas de certificados y usando las opciones de “Nuevo/Plantilla de certificado que se va a emitir”. En la lista seleccionamos nuestra plantilla: Firma de respuesta de OCSP
-Si no está instalado, hay que instalar el servicio OCSP desde el Server ManagerArrancamos la consola de Administrador del Servicio de Respuestas en Línea y agregamos una configuración de revocación
-Asignamos un nombre descriptivo del servicio
-El certificado para el OCSP nos lo emitirá la CA subordinada de empresa
-Examinamos los certificados desde el Directorio Activo y permitimos que OCSP automáticamente use el certificado para firmar las respuestas enviadas a los clientes
-**El servidor OCSP**
-Un único servidor OCSP puede publicar múltiples CA de la misma o de distinta PKI ya que se trata de un servicio web
-El servidor OCSP se puede publicar en Internet si se desea que se pueda consultar desde el exterior
-  * En ese caso, conviene que sea un servicio protegido por un cortafuegos
-  * Es una configuración típica instalar el servidor OCSP en un DMZ
-Publicación en OCSP de la CA raíz
-Seleccionamos el certificado desde local ya que la CA raíz o está en el DA
-Seleccionamos el certificado de la CA raíz y permitimos firmar con él las respuestas a los clientes
-Para nuestra CA raíz no tendremos un proveedor de listas de revocación y eso lo solucionamos introduciéndolo manualmenteHacemos clic en aceptar y luego mediante el botón de Proveedor introducimos la ruta a la lista de revocación de nuestra CA raíz
-Publicación de la CA raíz
-Aunque nosotros asignamos esta ruta en nuestra CA raíz, en realidad la lista de revocación no figura en esa ruta porque nosotros debemos de proveer el mecanismo por el cual el servidor con la CA Raíz pueda escribir en esa carpeta la lista de revocación
-Dado que nuestra CA se mantiene off-line, que el servidor no pertenece al dominio y que la cantidad de revocaciones que se van a hacer en este servidor van a ser mínimas lo más adecuado es copiar los archivos de forma manual
-Para hacerlo seguimos los siguientes pasos:
-  * Nos conectamos al recurso compartido donde la CA Raíz publica sus CRLs: \\srv-rootca\certenroll
-  * Copiamos el contenido de esa carpeta y lo pegamos en el recurso compartido de la CA subordinada: \\dc1\certenroll
-Si no hubiese contenido en el recurso compartido de la CA Raíz entonces tendremos que crear nuestra primera CRL
-Desde el servidor que alberga nuestra CA Raíz arrancamos la herramienta de administración de la CA
-Usando el menú contextual del contenedor Certificados Revocados publicamos nuestra primera CRL
-Obviamente esta CRL estará vacía a menos que hayamos revocado algún certificado
-Cada vez que generemos una nueva lista de revocación debemos copiar el contenido desde el servidor CA Raíz hacia el servidor CA Subordinado
-===== Agente =====
-Agente de recuperación de claves KRA (Key Recovery Agent)
-Tiene la capacidad de recuperar la clave privada de un certificado desde la base de datos de la CA que lo emitió
-Puede solucionar problemas de pérdida o extravío de certificados
-Debe asignarse a personas de muy alta confianza
-Pasos previos para su implementación:
-  * Se crea un usuario especial “UsuarioKRA”
-  * Se crea un grupo global “AgentesKRA”
-  * Se integra al usuario UsuarioKRA en el grupo AgentesKRA
-En la herramienta de administración de la CA abriremos el editor de plantillas usando el menú contextual de la carpeta Plantillas de Certificados

Seguridad y Alta Disponibilidad

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página