Exportar certificados cuya clave está marcada como no exportable en Windows

En algunos casos, tanto durante la importación de un certificado al sistema (desde un PFX) o desde la misma generación de una solicitud de certificado, la clave privada puede ser marcada como no exportable en Windows y esto se refleja de la siguiente manera cuando se intenta exportar el certificado y su clave privada:

Sin embargo, a diferencia de una clave privada almacenada en una tarjeta inteligente (donde es imposible exportar), en este caso, dado que la clave está almacenada en software, se puede usar la siguiente herramienta para permitir exportarla, Jailbreak.

A continuación se muestran las instrucciones para usar Jailbreak.

En primer lugar se requiere descargar la herramienta desde https://github.com/iSECPartners/jailbreak/archive/master.zip.

Después de lo cual se debe descomprimir el archivo descargado con lo que se verán las siguientes herramientas:

Después de esto se deberá abrir una línea de comandos en modo de administrador de la siguiente manera:

Luego se deberán ejecutar los siguientes comandos en esta línea de comandos:

Con lo cual se obtendrá la siguiente ventana de Microsoft Management Console (MMC), que funcionará de manera idéntica, salvo que sí permitirá exportar las claves, como se muestra a continuación:

Luego de lo cual el procedimiento es el mismo, se escoge la contraseña para el PFX y la ubicación del mismo.

Manual de instalación de certificado SSL en MS Exchange Server 2007

A continuación se describe el procedimiento dividido en dos partes:

1) Generación de solicitud de certificado a la autoridad certificadora correspondiente.

2) Instalación del certificado emitido por la autoridad certificadora.

Generación de solicitud de certificado

Primero, en el menú Inicio se debe escoger la opción “Exchange Management Shell” del menú “Microsoft Exchange Server 2007”:

image2017-1-10 11-38-28

Se abrirá una ventana de comandos. Allí se ejecutará el comando con el que se generará la solicitud de certificado para el dominio “mail.contoso.com”. Adicionalmente, se incluirá el dominio “AMAZON-E07145CA.contoso.com” como nombre alternativo (SAN), donde “AMAZON-E07145CA” corresponde en este caso al nombre del servidor en la red interna. El comando a ejecutar es el siguiente:

>New-ExchangeCertificate -GenerateRequest -Path c:\mail_contoso_com.csr -KeySize 2048 -SubjectName "c=PE, s=Lima, l=Lima, o=CONTOSO SA, ou=IT, cn=mail.contoso.com" -DomainName AMAZON-E07145CA.contoso.com -PrivateKeyExportable $True
El comando mostrado anteriormente puede construirse fácilmente utilizando la siguiente herramienta de la página de DigiCert: https://www.digicert.com/easy-csr/exchange2007.htm.

Aquí se muestra el resultado de la ejecución del comando:

image2017-1-10 14-58-40

Al término de la ejecución del comando anterior se contará con el archivo de solicitud en la siguiente ruta:

c:\mail_contoso_com.csr

Este archivo deberá ser enviado a la autoridad certificadora o a su representante local, quienes deberán responder positivamente adjuntando el certificado que han emitido.

Instalación y activación del certificado

Una vez recibido el certificado de la autoridad certificadora o de su representante local, este deberá ser copiado en alguna ubicación del servidor. En el presente ejemplo, se ha sido copiado el certificado en C:\mail.contoso.com.crt.

Luego de ello, se deberá volver a escoger en el menú Inicio la opción “Exchange Management Shell” del menú “Microsoft Exchange Server 2007”, y ejecutar el siguiente comando, con el que se importará el certificado al almacén del sistema.

>Import-ExchangeCertificate -path C:\mail.contoso.com.crt

En este punto se deberá tomar nota del código señalado en la imagen anterior, que corresponde al identificador o huella del certificado recién instalado.

image2017-1-10 12-27-1

Posteriormente, se deberá activar el uso de este certificado para cada uno de los servicios del Exchange Server. Esto se consigue mediante la ejecución del siguiente comando:

>Enable-ExchangeCertificate -Services IMAP, POP, IIS, SMTP -thumbprint 4902AB700B2AC28820C04DF1B799A2FFDCE0439A

Nótese que en este comando se requiere el código apuntado anteriormente.

image2017-1-10 12-30-34

Después de esto, para comprobar que el certificado ha sido instalado correctamente y activado para los servicios indicados, se ejecutará el siguiente comando:

>Get-ExchangeCertificate

Aquí se muestra el resultado de la ejecución del comando, con lo cual se verifica que el certificado ha sido activado para los servicios indicados (S: SMTP, I: IMAP, P: POP3, W: IIS).

image2017-1-10 12-37-1

Instalación de autoridades certificadoras intermedias

En este punto se deberán instalar los certificados de autoridad certificadora intermedia. En general, estos pueden ser obtenidos desde la página de la autoridad certificadora (ej. GeoTrust) y usualmente son enviados por correo junto con el certificado adquirido.

Para llevar a cabo esta instalación, se realizará la siguiente operación para cada uno de los certificados de autoridad certificadora intermedia.

En el ejemplo actual, este certificado tiene como nombre Test Purpose Intermediate CA - G2.crt y se procederá de la siguiente manera.

image2017-1-10 13-1-40

image2017-1-10 13-3-17

Después de importar las autoridades certificadoras intermedias es recomendable el reinicio de cada uno de los servicios que utilizan los certificados SSL (ej. IIS), siendo el reinicio del servidor lo más conveniente para actualizar la configuración de los certificados en todos los servicios involucrados.

Manual basado en https://www.sslshopper.com/article-how-to-use-ssl-certificates-with-exchange-2007.html.

¿Un Sistema de Intermediación Electrónica (SIE) debería operar una TSA?

Actualmente el procedimiento de acreditación de un Sistema de Intermediación Electrónica (SIE) en Perú ante la Autoridad Administrativa Competente (Indecopi) permite/promueve que se acredite el servicio de sellado de tiempo como parte del SIE, donde estos sellos de tiempo se utilizarían para firmar los acuses de recibo generados por el SIE. Pero hay un problema importante de seguridad al permitir/promover esto.

A continuación expongo algunos argumentos para justificar que un SIE no debería operar un servicio de sellado de tiempo.

Si planteamos el caso hipotético en el que cada empresa que genera firmas digitales (de documentos en general) llegara a acreditar una TSA también y la pudiera usar legalmente para sus propias operaciones, cada una de estas empresas podría generar firmas digitales con sellos de tiempo con fechas falsas (ej. pasadas).

Precisamente es por esto que los servicios de sellado de tiempo por su naturaleza deben ser provistos por una entidad distinta de la que los solicita. Nuevamente, sobre el hipotético caso anterior, aunque todas estas empresas contaran con una TSA acreditada, si estuvieran prohibidas de usar su propia TSA en sus operaciones, simplemente no podrian generar sellos de tiempo falsos (salvo que se coludan con una de las otras empresas que también operan una TSA).

Ahora, si mantenemos este mismo razonamiento, un SIE sería una empresa más que en este caso firma acuses de recibo y solicita sellos de tiempo para estos. Y con el razonamiento anterior, deberia solicitarlos de una TSA externa.

Además, si consideramos que un Sistema de Intermediación Electrónica (SIE) coincide con la definición de “Electronic Registered Delivery Services” en el contexto de la normativa europea y que para este tipo de servicio un estándar concreto es el “Registered Electronic Mail (REM)”, podemos hacer una cita de ETSI TS 102 640-1 V2.2.1, “Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail (REM); Part 1: Architecture”, donde se indica explícitamente que la TSA debería ser externa:

2016-12-27 19_27_27-ts_10264001v020201p.pdf (SECURED) - Adobe Acrobat Reader DC


The REM-MD architecture shall include a Certification Authority supporting role. Additionally the following supporting roles may be used by the ones listed above in support of their functions as described in figure 5: Signature Creation Server, Time-Stamping Authority (TSA) and Long Term Storage.

Time Stamping Authority is an independent entity that issues Time Stamping Tokens of the submitted digests (protocols specified in RFC 3161 [i.4] may apply).

Among these supporting roles the CA and TSA roles shall not be in sourced. These services are intended to provide an additional layer of trust that only an entity third is able to give.

WP Facebook Auto Publish Powered By : XYZScripts.com