CRL: Lista de revocación de certificados publicada en servidor externo

Dependiendo de la complejidad de la infraestructura PKI de la organización, podemos desde la entidad de certificación publicar automáticamente en servidores externos, en este caso IIS, los datos.

Para ello compartimos una carpeta en el equipo con el servidor web asignando permisos de acceso y NTFS sobre el nombre de la máquina.

Añadimos en la publicación de la CA una nueva ruta hacia nuestro servidor local, el nombre del fichero y la ruta final debe ser el mismo que el expuesto externamente para el CRL:

file://\\servidorLocal\CA\<nombre de CA><sufijo de nombre de lista CRL><diferencias entre listas CRL permitidas>.crl

En nuestra entidad de certificación tendremos de la siguiente manera la publicación interna y el acceso de consulta externo, por ejemplo:

 

Para asegurarnos que el servidor es capaz de alcanzar las rutas de publicación, con el botón derecho sobre "Certificados revocados" pulsamos "Todas las tareas" -> "Publicar"

 

Comprobar las listas de revocación desde equipo externo

Existe la alternativa de utilizar OCSP para la comprobación de las listas, lo veremos en otro momento.


Cambiar nivel de compatibilidad SQL Server de todas las bases de datos

Antes o después de ciertas migraciones podemos cambiar el nivel de compatibilidad SQL con el motor instalado. Si desconocemos la versión, podemos obtenerlas con la siguiente consulta:

SELECT SERVERPROPERTY('ProductVersion');  

Así como el nivel actual de las bases de datos:

SELECT name, compatibility_level FROM sys.databases;

Para realizar el cambio a todas, excepto las 4 primeras del sistema:

declare @nivel_compatible  varchar(max)
set     @nivel_compatible  = ''
select  @nivel_compatible = @ nivel_compatible +

from   sys.databases
where  database_id > 4 and compatibility_level not in ('100')
exec   (@ nivel_compatible)

En este ejemplo cambiaríamos el nivel de compatibilidad de las que no son 100 a 100, jugando con la clausula WHERE de la instrucción podemos realizar los cambios que necesitemos.

 

Fuente: Diferencias entre niveles de compatibilidad

Recuperar bases de datos MySQL desde ficheros

El motor de almacenamiento utilizado por MySQL/MariaDB hasta su versión 5.5 es MyISAM, en versiones posteriores se incorpora InnoDB.

A modo de resumen breve, dada la popularidad en entornos web en los que las consultas de lectura (SELECT) predominan sobre las de escritura (INSERT/UPDATE) sigue siendo una de las opciones más utilizadas en entornos en los que prima: velocidad, sin bloqueo de registros o tablas, sin características ACID (Atomicity, Consistency, Isolation, Durability) internas, recursos hardware limitados...

Cada una de las bases de datos generadas en su directorio contiene 3 ficheros por cada tabla con extensiones:

  • FRM: definición de la esctructura de la tabla
  • MYD: datos almacenados
  • MYI: índices

Podemos copiar desde entornos linux a windows y viceversa, con la consideración de dar los permisos suficientes de acceso sobre los ficheros.

  • En Windows: C:\ProgramData\MySQL\MySQL Server 5.X\data
  • En Linux: /var/lib/mysql/

Puedes conocer el directorio de datos realizando consulta en las variables globales:

mysql -s -N -uUSER -p information_schema -e 'SELECT Variable_Value FROM GLOBAL_VARIABLES WHERE Variable_Name = "datadir"'

O realizando la consulta sobre la variable directamente:

select @@datadir;

Una vez localizado los directorios, debemos parar el servicio MySQL, copiar la carpeta completa de nuestra base de datos en el directorio y asignar los permisos de acceso.

Los índices puedes ser regenerados o reparados mediante sentencias posteriormente:

check table nombreTabla;

repair table nombreTabla

 

"Recuperar" claves privadas de certificados SSL en IIS

En ocasiones es posible tener alguna que otra dificultad a la hora de crear peticiones (CSR) o renovar si no se realizan los pasos con cuidado en IIS. Debemos tener en cuenta que a la hora de crear una petición de certificado, la clave privada se almacena en el equipo que la realiza y solo en este es posible recuperarla.

Pese a ello en ocasiones se producen errores en el proceso, llegados a este extremo podemos intentar dos opciones:

  1. Desde la linea de comandos podemos intentar reparar el almacen de certificados:
    certutil -repairstore my "ThumbprintDelCertificadoConoSinEspacios"
    Si el comando encuentra las claves privadas asociadas al certificado indicado con el thumprint las asocia, en otros casos es posible que muestre errores del tipo "Insertar tarjeta inteligente" ya que busca en todos los medios y proveedores criptográficos existentes, en tal caso no podrá acabar.

  2. Si hemos solicitado el certificado a una autoridad online, es posible que tenga almacenadas las claves privadas en la solicitud web, en este caso podremos unirlas con el certificado de respuesta para obtener el PFX resultante mediante OpenSSL, puedes probar online pero nunca en producción
    openssl pkcs12 -export -inkey clave.pem -in pki.crt -out certificadoCompleto.pfx

 

.NET Framework hoy y mañana

En ciertas ocasiones, más habituales de lo que uno desearía, te encuentras en la obligación de interactuar con componentes antiguos... muy antiguos... si hablamos de un COM en Visual Basic 6 nos remitimos 20 años atrás. Si la evolución del software y hardware cada 6 meses puede ser notable, en algunos ámbitos la adopción de ciertos hitos tecnológicos lleva décadas.

Existe una mejora y facilidad de uso entre los Common Language Runtime (CLR), aunque Microsoft le encanta cambiar y variar los nombres (Project K, vNext...) , intentaremos resumir...

Actualmente la definición de .NET Standard intenta facilitar a los desarrolladores una API común para aplicaciones de escritorio, móvil, juegos y cloud, tenemos por un lado Full Framework y por otro lado Core Framework, dos ramas con diferentes propósitos.

  • Full Framework es monolítica, instalas todo o nada solo para Windows
  • Core Framework es modular, puedes referenciar solo las partes que utilices para entorno Windows, Linux o Mac, además es Open Source y con web/Cloud en mente inicialmente.
  • Dejamos Xamarin como multiplataforma a partir de la evolución de Mono (Linux) cuando Microsoft no quería llevar .NET fuera de Windows (eran otros tiempos sin iOS ni Android...)

A futuro Microsoft parece querer unificar toda su tecnología sobre C# en .NET Core: Entity (ORM), WPF, MVC, SignalR, MVC, Web API... pero hasta entonces tenemos largos años de Full Framework todavía ¿cuantos?