====== 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/_.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/.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 {{:sad:t1:imagen51.png?400|}} El servicio OCSP se identifica con un certificado específico de OCSP {{:sad:t1:imagen52.png?400|}} 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” {{:sad:t1:imagen53.png?400|}} 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 {{:sad:t1:imagen54.png?400|}} 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 {{:sad:t1:imagen55.png?400|}} Si no está instalado, hay que instalar el servicio OCSP desde el Server Manager Arrancamos la consola de Administrador del Servicio de Respuestas en Línea y agregamos una configuración de revocación {{:sad:t1:imagen56.png?400|}} Asignamos un nombre descriptivo del servicio {{:sad:t1:imagen57.png?400|}} El certificado para el OCSP nos lo emitirá la CA subordinada de empresa {{:sad:t1:imagen58.png?400|}} Examinamos los certificados desde el Directorio Activo y permitimos que OCSP automáticamente use el certificado para firmar las respuestas enviadas a los clientes {{:sad:t1:imagen59.png?400|}} {{:sad:t1:imagen60.png?400|}} **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 {{:sad:t1:imagen61.png?400|}} {{:sad:t1:imagen62.png?400|}} Seleccionamos el certificado de la CA raíz y permitimos firmar con él las respuestas a los clientes {{:sad:t1:imagen63.png?400|}} {{:sad:t1:imagen64.png?400|}} Para nuestra CA raíz no tendremos un proveedor de listas de revocación y eso lo solucionamos introduciéndolo manualmente Hacemos 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 {{:sad:t1:imagen65.png?400|}} {{:sad:t1:imagen66.png?400|}} **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 {{:sad:t1:imagen67.png?400|}} 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 {{:sad:t1:imagen68.png?400|}} ===== 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 {{:sad:t1:imagen69.png?400|}} En el administrador de plantillas localizamos la plantilla Agente de recuperación de claves y hacemos doble clic sobre ella para acceder a sus propiedades En la pestaña Seguridad agregamos al grupo Agentes KRA y le asignamos el permiso de Inscribirse y el de lectura {{:sad:t1:imagen70.png?400|}} Para que no sea necesario que un administrador autorice la emisión de estos certificados quitamos la marca que hay en la casilla Aprobación del administrador de certificados de entidad de certificación en la pestaña Requisitos de Emisión. En entornos de alta seguridad podría ser conveniente dejar esta marca activada para que la emisión de estos certificados estuviese controlada por los administradores {{:sad:t1:imagen71.png?400|}} A continuación tenemos que permitir la emisión de esta plantilla Para ello en el menú contextual de la carpeta de certificados elegimos nuevo – Plantilla de certificado que se va a emitir y seleccionamos la plantilla del Agente de Recuperación de Claves {{:sad:t1:imagen72.png?400|}} **Creación del certificado del KRA** A continuación debemos de solicitar el certificado de KRA para el usuario que le corresponda * Iniciamos una sesión con el usuario KRA desde cualquier máquina en el dominio * Si lo vamos a hacer desde el controlador de dominio debemos de recordar que los usuarios básicos no pueden iniciar sesión en este tipo de servidores Para solicitar el certificado KRA para este usuario vamos a usar la consola MMC * Desde una sesión de ese usuario arrancamos una consola MMC en blanco y agregamos el complemento de certificados * Si se nos solicita a que tipo de contenedor de certificados queremos acceder seleccionamos el de usuario * Si tenemos activado el control de cuentas en el sistema operativo tendremos que ingresar de nuevo la contraseña de nuestro usuario para confirmar el uso de la consola MMC Desde la consola MMC accederemos al menú contextual del contenedor Personal para llegar a la opción de Solicitar un nuevo certificado {{:sad:t1:imagen73.png?400|}} En el asistente seleccionaremos el certificado Agente de Recuperación de claves {{:sad:t1:imagen74.png?400|}} **Preparación de la CA para que almacene las claves privadas** * Arrancamos la herramienta de administración de nuestra CA de Empresa y accedemos a sus propiedades haciendo clic con el botón derecho sobre el nombre de la CA * En la pestaña Agentes de Recuperación activamos el botón de Archivar la Clave y agregamos el certificado o los certificados correspondientes a todos los agentes de recuperación que hayamos designado. En este punto veremos que certificado se marca con una aspa roja y que en su estado figura “no cargado” * Esto es porque necesitamos reiniciar los servicios de la CA. Hacemos clic en Aceptar y reiniciamos los servicios * Una vez reiniciado el servicio podremos volver a consultar esta pestaña para ver que ahora los certificados están activos {{:sad:t1:imagen75.png?400|}} **Definición de los tipos de certificados cuya clave privada será respaldada** Se define una plantilla de usuario o varias, dependiendo del uso que se le vaya a dar a cada una de ellas y también debemos de definir en cada una de esas plantillas a cuales les queremos respaldar su clave privada * Volvemos al editor de plantillas de nuestra CA haciendo uso del menú contextual de la carpeta de plantillas * Desde este editor vamos a hacer clic con el botón derecho sobre la plantilla que se llama Usuario y seleccionamos la opción de plantilla duplicada * Con esto conseguimos una copia de esa plantilla que nosotros vamos a adaptar a nuestras necesidades sin modificar la original * Seleccionamos la opción de Windows Server 2008 al crear la nueva plantilla * Automáticamente se nos abren las propiedades de la nueva plantilla Para empezar vamos a asignarle un nombre En este caso usaremos Usuario Corporativo (Clave Archivada) {{:sad:t1:imagen76.png?400|}} A continuación en la pestaña Tratamiento de la Solicitud tendremos que activar la casilla: Archivar clave privada de cifrado de sujeto Esta opción es la que permitirá archivar la clave privada del certificado {{:sad:t1:imagen77.png?400|}} Tendremos que modificar sus permisos para que se puedan distribuir los certificados basados en esta plantilla de forma automática mediante Directivas de Grupo. Para ello asignamos al grupo Usuarios Autentificados los permisos de lectura, inscribirse e inscripción automática. También podríamos restringir estos permisos a grupos más reducidos dependiendo de como queremos asignar certificados a nuestros usuarios {{:sad:t1:imagen78.png?400|}} A continuación solo resta publicar la plantilla en la CA mediante el menú contextual de la carpeta Plantillas de certificados Nuestra CA de Empresa debería de tener un aspecto similar al siguiente {{:sad:t1:imagen79.png?400|}} **En este punto se puede desconcetar la CA raíz** ---- ===== Distribución de los certificados a los usuarios ===== **Distribución desde el Directorio Activo** Ya tenemos lista nuestra CA para poder comenzar a distribuir certificados * El siguiente paso sería crear una GPO en el directorio activo que se encargue de distribuir los certificados Abrimos la herramienta de administración de las directivas de grupo dentro de las herramientas administrativas y creamos una GPO a nivel de dominio o al nivel de las OUs donde queremos distribuir certificados Editamos la directiva que acabamos de crear y nos vamos a: Configuración de Usuario – directivas – Configuración de Windows – Configuración de Seguridad – Directivas de clave pública Aquí hacemos clic sobre Cliente de Servicios de Certificate Server – Inscripción Automática {{:sad:t1:imagen80.png?400|}} Lo habilitamos y activamos las casillas de renovaciones automáticas y actualizaciones de plantillas {{:sad:t1:imagen81.png?400|}}