CERTIFICATE SERVICES - DISASTER RECOVERY

Por Martin Kirtchayan

La mayoría de los problemas que se producen durante el uso de certificado son el resultado de una configuración incorrecta o incompleta. Por ejemplo, importar un certificado en un contenedor de certificados erróneo, el certificado incorrecto en el contenedor correcto o ingresar incorrectamente la información al momento de solicitar un certificado, como también inconvenientes al publicar las CRL´s, o especificar ubicaciones, que en realidad no están disponibles, para publicar el CDP (CRL Distribution point) o el AIA (Authority Information Access), inconvenientes a intentar renovar certificados, y así podríamos seguir…

En esta ocasión, y en base a algunos casos que se presentaron últimamente, vamos a ir a uno de los puntos críticos de problemas con certificados,  la restauración del servicio, de PKI.

Vamos a ver qué pasos realizar para la restauración del servicio de certificados, por lo cual plantearemos dicha tarea sobre dos escenarios diferentes.

1. Restauración del servicio de certificados sobre el mismo equipo
2. Restauración del servicio de certificados  sobre un equipo diferente.

Antes que nada, quisiera comentar que no vamos a hablar sobre el planeamiento, documentación, practicas recomendadas ni sobre conceptos de PKI ya que es un tema un poco extenso (lo dejaremos para otra ocasión), como quien dice, iremos directo al grano. J

En síntesis estas estos procesos se aplicarían, entre otras cosas, en base a los siguientes inconvenientes:

• Falla en el servicio de certificados
• Falla en el hardware que maneja este servicio
• Falla en la infraestructura de red

Los métodos para realizar copias de seguridad como de restauración del servicio de certificados, base de datos, llave publica/privada, etc., serian los siguientes

• System State Backups
• Manual Backups
• Backups “Binarios” (usando herramientas de creación de imágenes, como por ejemplo Norton Ghost, o Symantec Partition Magic) este método también puede requerir un backup manual o del System State. Se utiliza generalmente en Offline CA.

Nota: Si poseemos la base de datos de la CA, almacenada en un Hardware Security Module (HSM) el proceso de backup y restauración va a requerir realizarlo con la aplicación de terceros que sea entregada por el proveedor del dispositivo.

Cada método varia, más allá de la forma en que realiza la tarea, en el tipo de información que resguarda / restaura. Un resumen de ello sería el siguiente:

System State: la principal ventaja seria que este método es un “todo en uno” ya que con un solo proceso estaríamos resguardando la base de datos de la CA, el par de llaves de la CA, la base de datos de IIS (es muy importante si hemos hecho alguna modificación en el web-enrollment, ya que dichos cambios se guardan allí) todas las llaves de registro relacionadas con Certificados

Manual: Este puede realizarse tanto desde la consola de de administración de certificados, como también, desde la línea de comandos, utilizando el comando certutil.Tengamos en cuenta que con este método, tanto las llaves de registro relacionadas a la CA, como también la base de IIS, no son resguardadas, por lo deben resguardarse de manera separada, para asegurar que tendremos una restauración completa y consistente del servicio de certificados.

Dicho esto, vamos a realizar el proceso de restauración del servicio de certificados en nuestro primer escenario, que trata sobre restaurar el servicio en el mismo equipo.

Solo como información, en el ambiente en que se desarrollo el laboratio es un dominio Windows Server 2003. La CA es Enterprise root CA.

Bien, comenzaremos con el paso de tomar un backup de la CA, antes de simular la falla, para tener nuestro respaldo. Tal como comentábamos, poseemos varios métodos para realizar este proceso, en mi caso tomare el método manual, utilizando el comando certutil, nos tomara un poco de trabajo más, pero así podremos ver los diferentes pasos para realizar la tarea.

Lo primero que debemos verificar es que el servicio de certificados este en ejecución, o lo verificamos desde la consola, o ejecutamos el comando “net start certsvc”

A continuación creamos una carpeta donde almacenaremos la copia de seguridad, por ejemplo: C:\CAbkp. Una vez creada la carpeta ejecutaremos el comando certutil –backup c:\CAbkp para realizar el backup, nos va a pedir un password, el cual se utiliza para proteger el archivo PKCS #12 que contiene el par de llaves de la CA.

Asegúrense de no recibir ningún error en pantalla.

A modo de comentario, los siguientes comandos y su descripción:

Certutil –backupdb c:\CAbkpresguardara solamente la base de datos de la CA

Certutil –backupkey c:\CAbkpresguardara solamente el par de llaves de la CA

Como comentaba, este método no es “Todo en uno” sino que debemos resguardar los datos de manera separada. Ahora necesitamos resguardar los datos del registro, para lo cual exportaremos la llave “CAName”, la cual resguarda la configuración de la CA, en mi caso EntRootCA, desde la siguiente ubicación:

El tercer punto sobre el que deberíamos realizar el backup es sobre el IIS (obviamente si estamos utilizando web-enrollment, sobre el cual hemos realizado alguna modificación, caso contrario no tendría mucho sentido, ya que, como veremos más adelante, el servicio de certificados será reinstalado)

Siguiendo con nuestro escenario, ya tenemos el backup, ahora, vamos a regenerar un problema.

Básicamente el problema que tenemos es que no podemos acceder a un sitio web seguro   que, ya que el certificado se encuentra revocado, recibiendo el mensaje en el explorador,

Por lo cual intentamos emitir un nuevo certificado, pero nos encontramos con que el servicio de certificados no inicia. Y recibimos el siguiente mensaje:

En síntesis no se encuentra el par de llaves de la CA. (La cual, para generar esta situación, eliminamos)

Más allá del método que vayamos a utilizar lo primero que deberíamos realizar es reinstalar la consola de certificados, reinstalando la consola de certificados nos aseguramos de que el servicio se encuentra instalado correctamente. Durante la reinstalación del servicio utilizaremos el certificado de la CA y el par de llaves originales (sobre los cuales habíamos hecho un backup) así nos aseguramos  que se utilice el mismo par de llaves para las operaciones de firmas de certificados, y mantener la validez de los certificados ya emitidos.

Procedemos a desinstalar el componente de certificados. Una vez hecho esto, antes de  reinstalarlo, debemos agregar el certificado PKCS #12 (el cual resguardamos al realizar el backup) en el contenedor de certificados de la CA. Podemos importarlo, siguiendo el asistente.

Le indicamos donde se encuentra el certificado

Nos va a solicitar el password (ingresamos el mismo que especificamos a realizar el backup)

Le indicamos en que contenedor se ubicara el certificado, y finalizamos el asistente, nos debería quedar como sigue:

Desde la consola de agregar o remover componentes de Windows, reinstalamos el componente “Certificate Services” (este proceso no requiere reinicio) como sigue:

1. En la ventana para seleccionar el tipo de CA, seleccionamos el mismo tipo que poseía antes, y habilitamos la opción “Use Custom Settings To Generate the Key Pair and CA Certificates”. Next

2. En Public and Private Key Pair, seleccionamos las siguientes opciones

• • CSP: la misma opción que teníamos antes
  • Use an existing key: habilitado
  • Seleccionamos el certificado con el mismo nombre de CA, (el cual habíamos resguardado)
  • Use the certificate associated with this key: habilitado

(El algoritmo de hash, y el tamaño de la llave, lo dejamos como esta porque se cambiará automáticamente en base al que teníamos previamente configurado)

3. En la siguiente opción, solo verificamos que el nombre de identificación y periodo de validez sean correctos, click en  next

4. En Certificate Database Settings, verificamos que las rutas sean las correctas, a como teníamos previamente configurada la CA. Y “deberíamos” habilitar la opción de “Preserve existing certifícate database”

Si después de finalizado el proceso, el servicio de certificados no inicia, intenta realizar este proceso nuevamente, pero sin habilitar la opción de “Preserve existing certifícate database” ya que el error puede deberse a la base de datos o archivo de log corrupto. Una vez que reinstalaste, podes restaurar la base desde un backup.

5. En mi caso y con propósito de esta demostración, voy a dejar la opción “Preserve existing certifícate database” deshabilitada. Simulando que la base de datos que preexistía se encontraba dañada.

6. Nos va a informar que el servicio de IIS se reiniciara, click en “Yes”

7. Finalizamos el asistente.

Obviamente, al no preservar la base de datos existente, no vamos a tener la información referente a que certificado se emitió, cual se revoco, CRL`s, etc., por lo cual vamos a realizar la restauración de esta información.

Abrimos la consola de certificados, click derecho sobre la CA -> all task -> Restore CA… (Este proceso detendrá el servicio de certificados).

Seleccionamos que deseamos restaurar la base de datos y los logs, como se muestra a continuación

Finalizamos y el servicio de certificados iniciara automáticamente.

Ya podemos ver nuestra base de datos

Ya tenemos el servicio de certificados funcionando nuevamente, procedemos a emitir un nuevo certificado web, e intentamos acceder nuevamente al sitio…. El cual ya está funcionando.

En nuestro segundo escenario, supongamos que el servidor EntRootCA, está dañado, o el hardware no cumple con los requisitos que necesitamos, sea cual fuese la situación, el tema es que tenemos que mover el servicio de certificados desde este equipo a uno nuevo.

En este proceso necesitamos utilizar el método manual (el System State realiza copias de otra información que nos sería compatible en el nuevo servidor si intentamos restaurarla.)

Básicamente, el proceso es similar al descripto con anterioridad, vamos a resguardar…

1. Base de datos de la CA
2. Las llaves de la CA
3. La llave de registro: HKLM\SYSTEM\CCS\Services\CertSvc\Configuration\EntRootCA
4. El archivo de configuración CAPolicy.inf (si existe) que se encuentra dentro de la carpeta %windir%

Lo importante acá es que el nuevo equipo tenga el MISMO nombre NetBIOS y DNS que el servidor que estamos removiendo.

Una vez que removimos la antigua CA, agregamos la nueva CA al dominio, con el mismo nombre, si las entradas DNS son estáticas, verifiquemos que la configuración IP del nuevo servidor sea la misma que el viejo servidor.

Una vez agregado el nuevo servidor al dominio, procederemos a realizar la instalación del componente de Certificate Services

Como hicimos durante el primer escenario, seleccionamos el mismo tipo de CA que el tipo que poseía la CA que estamos reemplazando, seleccionamos la opción “Use custom settings to generate the key pair and CA certifícate”

En la siguiente ventana, seleccionamos el certificado de la CA que veníamos utilizando,

En este caso el certificado no fue importado al contenedor de certificados, sino que seleccione la opción “Import” donde especifique la ruta donde se encuentra la llave como también el password que se uso al exportarla / resguardarla.

Continuamos con el paso de revisar la información de la identificación de la CA, al seleccionar next, vamos a recibir un mensaje informando que se encontró una CA con el mismo nombre en Active Directory (esta información se guarda en la partición de Configuración) pueden verla desde la consola de Active Directory Site and services (seleccionando View -> Show Service node -> Public Key Services) o utilizar Adsiedit o LDP.

Seleccionamos “Yes”, y continuamos con la selección sobre donde se almacenara la base de datos, pero en esta ocasión no podemos especificar que vamos a preservar la base existente, ya que es una instalación limpia. Y no hay ninguna base preexistente.

Una vez finalizada la instalación revisamos que el servicio se inicie correctamente.

Posterior a ello vamos a restaurar la llave de registro con la información sobre la configuración de la CA

Restauramos la base de datos, como hicimos en el anterior escenario.

Verificamos que el servicio este en ejecución.

Como vemos, ya tenemos nuestra CA Funcionando y con nuestra base de datos de certificados en ejecución.

Si se va a volver a agregar a la antigua CA al dominio nuevamente, no hay que olvidar renombrarla para evitar conflictos de nombres!!

Bien, espero que esta información les sea de utilidad, mucha suerte y hasta pronto.

Información Relacionada:

• Windows Server 2003 PKI Operations Guide
• Backing up and restoring a certification authority
• How to move a certification authority to another server
• How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows Server 2000