Administración de certificados digitales en Windows Azure


Uno de los temas que podría interesarnos sobre la plataforma Windows Azure es si existe la posibilidad de administrar certificados digitales. Lo primero que debemos saber acerca de los certificados utilizados en Azure es lo siguiente:



  1. A día de hoy, podemos subir un total de 5 certificados a través del portal.

  2. El estándar utilizado es X.509.

  3. Es posible revocar cualquiera de ellos en cualquier momento.

  4. Son necesarios para realizar tareas con la API de administración.

  5. Podemos utilizar certificados firmados por nosotros mismos.

  6. Los certificados deben utilizar la extensión .cer.

Generar nuestros propios certificados


Para poder experimentar y/o testear nuestra aplicación podríamos hacer uso de un certificado creado por nosotros mismos. Una forma de generarlos es a través de la herramienta makecert utilizando la línea de comandos. El primer paso para comenzar a utilizar la herramienta es acceder a la consola Visual Studio Command Prompt, alojada en Visual Studio Tools, con privilegios de administrador. Un comando válido podría ser el siguiente:

makecert -pe -r -n «CN=ReturnGis» -a sha1 -len 2048 -ss My «MiCertificado.cer»

Más información sobre makecert.


Agregar certificados


Dependiendo del entorno en el cual queramos hacer uso de nuestro certificado, el modo de añadirlo es distinto.


Máquina local


El primer paso para asociar un certificado en el entorno de desarrollo es ubicar el mismo en el almacén de certificados para que sea localizado. Desde el menú de inicio ejecutamos el comando mmc y agregamos el complemento Certificados, administrando los certificados de Cuenta de equipo. Dejamos marcado Equipo local y pulsamos Finalizar para terminar con el asistente.



Nos posicionamos en el apartado Personal y a través del botón derecho seleccionamos Todas las tareas => Importar y seleccionamos el certificado que acabamos de crear. Pulsamos «Siguiente» en cada una de las ventanas, hasta finalizar el asistente 😀


Abrimos nuestro proyecto en Visual Studio y hacemos doble click en la carpeta Roles sobre el rol donde vamos a utilizar el certificado. Una vez dentro de la configuración, vamos al tab Certificates y añadimos uno nuevo. Si hacemos click en el botón de Thumbprint, nos aparecerán todos los certificados que tenemos disponibles. En este caso aparecería solamente uno que es el que acabamos de crear 😉 Lo seleccionamos y aceptamos.



Si nos fijamos en el archivo ServiceDefinition.csdef vemos un nuevo apartado Certificates:

<?xml version=»1.0″ encoding=»utf-8″?>
<ServiceDefinition name=»Certificates» xmlns=»http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition»>
  <WebRole name=»CertificatesWebRole»>
    <InputEndpoints>
      <InputEndpoint name=»HttpIn» protocol=»http» port=»80″ />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name=»DiagnosticsConnectionString» />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name=»Certificate» storeLocation=»LocalMachine» storeName=»My» />
    </Certificates>
  </WebRole>
</ServiceDefinition>

En este nuevo apartado, vemos toda la información mostrada en la UI del Role excepto el Thumbprint. El motivo es debido a que la firma del certificado se encuentra alojada en ServiceConfiguration.cscfg.

<?xml version=»1.0″?>
<ServiceConfiguration serviceName=»Certificates» xmlns=»http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration»>
  <Role name=»CertificatesWebRole»>
    <Instances count=»1″ />
    <ConfigurationSettings>
      <Setting name=»DiagnosticsConnectionString» value=»UseDevelopmentStorage=true» />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name=»Certificate» thumbprint=»9CC153A44988BF6E295C6788AFDC446227414BB1″ thumbprintAlgorithm=»sha1″ />
    </Certificates>
  </Role>
</ServiceConfiguration>

El objetivo de ello es que podamos ser capaces de modificar dicho certificado sin tener que hacer un nuevo deploy de toda la aplicación, ya que no es posible modificar ServiceDefinition.csdef sin tener que hacerlo (a diferencia de ServiceConfiguracion.cscfg).


Live Production


Cuando estemos dispuestos a subir los certificados a la nube, debemos hacerlo a través del portal. Seleccionamos el proyecto en la pestaña Windows Azure sobre el cual queremos utilizarlos (si es que tenemos más de uno) y hacemos click sobre la pestaña Account.



En este caso, seleccionamos el apartado Manage My API Certificates.



Lo único que debemos hacer es subir el archivo .cer correspondiente al certificado y automáticamente se agregará a la tabla de certificados instalados. Si quisiéramos asociar un certificado subido a la nube con la aplicación una vez en producción, bastaría modificar el archivo ServiceConfiguration.cscfg e incluir el Thumbprint correcto.


Configurar el endpoint https para utilizar el certificado


Una vez que hemos configurado el certificado en el tab Certificates, podemos enlazar el mismo a nuestro endpoint https a través del tab Endpoints desde el editor. Para poder hacerlo, basta con activar HTTPS y seleccionar nuestro certificado en SSL certificate name.



El resultado de esta configuración podríamos verlo en el archivo ServiceDefinition.csdef

<?xml version=»1.0″ encoding=»utf-8″?>
<ServiceDefinition name=»Certificates» xmlns=»http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition»>
  <WebRole name=»CertificatesWebRole»>
    <InputEndpoints>
      <InputEndpoint name=»HttpIn» protocol=»http» port=»80″ />
      <InputEndpoint name=»HttpsIn» protocol=»https» port=»443″ certificate=»Certificate» />
    </InputEndpoints>
    <ConfigurationSettings>
      <Setting name=»DiagnosticsConnectionString» />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name=»Certificate» storeLocation=»LocalMachine» storeName=»My» />
    </Certificates>
  </WebRole>
</ServiceDefinition>

Como podemos ver, la información en este archivo es mínima para poder modificar la firma dependiendo del entorno en el que estemos :) .


¡Saludos!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *