KomuraSoft LLC
Contáctenos
Menú

Guía práctica del almacén de certificados de Windows — ¿en el de usuario o en el de equipo?

· Actualizado el: · · Certificados, Windows, Seguridad, PKI, TLS, PowerShell, Aplicaciones empresariales, Sistemas de información

«Al renovar el equipo para la confirmación de elegibilidad en línea, reinstalé el certificado de cliente en el PC nuevo y dejó de poder conectarse», «En la máquina de desarrollo se conecta sin problemas a la API bancaria, pero al convertirlo en servicio de Windows dice que “no encuentra el certificado”», «Ni siquiera sé cuál es el auténtico: el certificado que veo en certmgr.msc o el que veo en certlm.msc»: cuando uno desarrolla por encargo integraciones con API web que requieren certificado de cliente, este tipo de consultas llegan con regularidad.

La confirmación de elegibilidad en línea de centros médicos, los trámites electrónicos, las API del sector bancario, el EDI con socios comerciales. El certificado de cliente, que antes solo tocaba el personal de infraestructura de las grandes empresas, hoy lo manejan también los responsables de sistemas y los desarrolladores de aplicaciones empresariales de pequeñas y medianas empresas. Y los incidentes relacionados con certificados se reducen, en realidad, a un puñado de patrones. Colocarlo en el lugar equivocado, olvidar el permiso de la clave privada y olvidar el vencimiento: estos tres.

Este artículo se dirige a los desarrolladores de aplicaciones empresariales que usan certificados de cliente y a los responsables de sistemas encargados de renovarlos. Tomando como eje la decisión de «¿almacén de usuario o almacén de equipo?», recorre de un tirón la estructura del almacén de certificados de Windows, la concesión de permisos sobre la clave privada, el inventario de vencimientos con PowerShell y el código de uso desde .NET. El contenido se basa en las fuentes primarias de Microsoft Learn vigentes en agosto de 2026.

1. Conclusión principal

  • El almacén de certificados de Windows tiene dos sistemas: «usuario» (CurrentUser) y «equipo» (LocalMachine). El almacén de usuario es distinto para cada cuenta (bajo HKEY_CURRENT_USER del registro); el almacén del equipo es común a todo el PC (bajo HKEY_LOCAL_MACHINE). 12
  • También hay dos herramientas de administración. certmgr.msc abre el almacén del usuario actual y certlm.msc el del equipo local. Desde PowerShell son Cert:\CurrentUser y Cert:\LocalMachine. 34
  • El almacén que corresponde se decide según «como quién se ejecuta el programa que usa ese certificado». Como regla general, el almacén de usuario para aplicaciones de un usuario interactivo, y el almacén del equipo para la ejecución desatendida de un servicio de Windows, IIS o el Programador de tareas (tabla de decisión del capítulo 3).
  • El motivo de «funcionaba en desarrollo, pero no se encuentra al convertirlo en servicio» es prácticamente uno solo. Un certificado que el desarrollador colocó en su propio almacén de usuario no es visible desde el CurrentUser de un servicio que se ejecuta con otra cuenta (capítulo 3).
  • El certificado y la clave privada son cosas distintas. Con solo colocarlo en el almacén del equipo, lo habitual es que la cuenta de servicio no pueda leer la clave privada. Conceda permiso de lectura a la cuenta de ejecución desde «Administrar claves privadas» en certlm.msc. 5
  • Al importar un pfx, la clave privada queda como no exportable de forma predeterminada. Import-PfxCertificate la incorpora de modo que no se puede volver a exportar, salvo que se indique -Exportable. Esto no es un fallo, sino un valor predeterminado deseable. 6
  • El vencimiento se previene automatizando el inventario. Con algo como Get-ChildItem Cert:\LocalMachine\My -ExpiringInDays 60 se pueden extraer mecánicamente los certificados que vencen dentro del número de días indicado. 4
  • Fijar la huella digital (thumbprint) en el código o en la configuración deja de funcionar en cada renovación del certificado, porque un certificado nuevo siempre cambia de huella digital. Externalizar el valor a la configuración y prever un periodo de convivencia entre el certificado antiguo y el nuevo es la base del diseño (capítulos 5 y 7).

2. Panorama general del almacén de certificados — dos ubicaciones y almacenes lógicos

2.1. Los dos sistemas: usuario y equipo

El almacén de certificados de Windows se divide, en términos generales, en dos «ubicaciones». 1

  • Almacén de certificados del equipo (equipo local, LocalMachine): hay uno solo por PC y es común a todos los usuarios y servicios de ese equipo. Reside físicamente bajo HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates del registro. 2
  • Almacén de certificados del usuario (usuario actual, CurrentUser): es distinto para cada cuenta de usuario. Reside físicamente bajo HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates, es decir, forma parte del perfil del usuario. 2

Además de estos, existe también un almacén por cuenta de servicio 3, cuyo soporte físico es una clave de registro por cada nombre de servicio. 2 En la práctica, lo primero que hay que dominar son los dos primeros.

Hay una especificación importante: cada almacén lógico del usuario, salvo el de «Personal», muestra por herencia el contenido del almacén del equipo que tiene el mismo nombre. 1 Por ejemplo, si se coloca el certificado de una CA interna en «Entidades de certificación raíz de confianza» del almacén del equipo, ese certificado aparece también en el almacén «Entidades de certificación raíz de confianza» de todos los usuarios. Dicho a la inversa, solo el almacén «Personal» no se hereda, así que el certificado de cliente (el que se coloca en el almacén Personal) exige decidir uno mismo «quién necesita verlo». Esta asimetría es la protagonista de todo este artículo.

Los dos sistemas del almacén de certificados: equipo y usuarioMuestra los almacenes lógicos Personal, Raíz, CA intermedia y Editores de confianza tanto en el almacén del equipo como en el del usuario, y cómo el almacén del equipo hereda su contenido hacia el del usuario salvo en el almacén PersonalUsuario (CurrentUser)Distinto para cada cuentaEquipo (LocalMachine)Uno por PC · común a todos los usuarios y serviciosSe ve por herencia de contenidoHerenciaHerenciaPersonal (My)*No se hereda: usted decide dónde colocarlo*Entidades de certificación raíz de confianza (Root)Entidades de certificación intermedias (CA)Editores de confianza (TrustedPublisher)Personal (My)Entidades de certificación raíz de confianza (Root)Entidades de certificación intermedias (CA)Editores de confianza (TrustedPublisher)

2.2. Los principales almacenes lógicos

Dentro de cada ubicación, el contenido se divide en almacenes lógicos según su función. Son las carpetas que se ven en certmgr.msc / certlm.msc, y al mirarlas desde PowerShell o la línea de comandos se usa el nombre interno en inglés. 24

Nombre visible Nombre interno Qué se coloca ahí
Personal My Los certificados que usa uno mismo (este PC, este usuario). Aquí van el certificado de cliente y el de servidor. También es donde se asocia la clave privada
Entidades de certificación raíz de confianza Root El certificado de la CA raíz que actúa como punto de partida de la confianza. Todo lo que cuelga de una CA colocada aquí queda «de confianza»
Entidades de certificación intermedias CA El certificado de la CA intermedia que conecta la raíz con el extremo. Es el material para construir la cadena
Editores de confianza TrustedPublisher Certificados de confianza como editores de software firmado (capítulo 8)

2.3. Tres ventanas para la misma información: certmgr.msc / certlm.msc / la unidad Cert:

Hay tres formas de ver el mismo almacén. 34

  • certmgr.msc: consola de administración que abre el almacén del usuario actual.
  • certlm.msc: consola de administración que abre el almacén del equipo local.
  • La unidad Cert: de PowerShell: permite manipular el almacén como si fuera un sistema de archivos, dentro de la jerarquía Cert:\CurrentUser... y Cert:\LocalMachine.… Los certificados se identifican por su huella digital.

Cabe señalar que, al agregar manualmente el complemento de certificados a mmc.exe, se elige el destino entre tres tipos: «cuenta de usuario», «cuenta de equipo» y «cuenta de servicio». Un usuario sin privilegios de administrador solo puede administrar el almacén de su propia cuenta de usuario. 3

El primer paso para investigar un problema es hacer coincidir «qué almacén está mirando la aplicación» con «qué almacén está mirando usted». Si investiga un fallo de un servicio mientras observa certmgr.msc, nunca llegará a la respuesta, porque está mirando un lugar distinto.

3. En qué almacén colocarlo — tabla de decisión según cómo se ejecuta el programa

El criterio de decisión es uno solo: ¿con la cuenta de quién se ejecuta el programa que usa ese certificado?

Forma de ejecución Cuenta de ejecución Almacén donde colocarlo Notas
Aplicación de escritorio que inicia un usuario interactivo El propio usuario que ha iniciado sesión Usuario (Cert:\CurrentUser\My) Hay que instalarlo en la cuenta de cada persona que lo use. Si varias personas comparten un PC, considere también el almacén del equipo
Servicio de Windows LocalSystem / NETWORK SERVICE / cuenta de servicio dedicada Equipo (Cert:\LocalMachine\My) Salvo LocalSystem (NETWORK SERVICE, cuenta dedicada, etc.), es obligatorio conceder permiso de lectura sobre la clave privada (capítulo 4). LocalSystem puede leerla con sus permisos de SYSTEM predeterminados
Aplicación web en IIS Identidad del grupo de aplicaciones Equipo Igual que arriba
Ejecución desatendida del Programador de tareas (se ejecute o no haya sesión iniciada) Cuenta indicada en la tarea Se recomienda el equipo También puede funcionar desde el almacén de usuario de la cuenta de ejecución, pero solo añade verificaciones sobre el perfil y la visibilidad del almacén, con poca ventaja real
Trámites electrónicos o autenticación web desde el navegador El propio usuario que ha iniciado sesión Usuario También tiene sentido en cuanto a que solo lo use la persona a quien se le entregó

Ante la duda: lo que se ejecuta sin supervisión va al almacén del equipo, y lo que opera una persona va al almacén de usuario.

3.1. Anatomía del error clásico: «funcionaba en desarrollo, pero no se encuentra al convertirlo en servicio»

Este incidente se puede reproducir con precisión siguiendo estos pasos.

  1. El desarrollador hace doble clic en el pfx en su propio PC para importarlo. Como el asistente tiene como valor predeterminado «Usuario actual», el certificado va al almacén de usuario de la cuenta del desarrollador.
  2. La aplicación en desarrollo se ejecuta desde Visual Studio, es decir, con la cuenta del desarrollador, así que al abrir StoreLocation.CurrentUser encuentra el certificado. Funciona.
  3. Se registra en el servidor de producción como servicio de Windows. El servicio se ejecuta con NETWORK SERVICE o una cuenta dedicada.
  4. El CurrentUser que abre el código del servicio es el almacén de usuario de la cuenta de ejecución del servicio. Ahí está vacío. «No se encuentra el certificado».
Anatomía del error "funciona en desarrollo pero no se encuentra en producción"Compara el flujo en la máquina de desarrollo, donde el certificado importado va al almacén de usuario del desarrollador y el código lo encuentra en CurrentUser, con el flujo en el servidor de producción, donde el servicio se ejecuta con otra cuenta y su CurrentUser está vacíoServidor de producciónMáquina de desarrolloSe despliega el mismo programaEl CurrentUser que abre el código esel almacén de usuario de la cuenta de servicioSe registra como servicio de WindowsLa cuenta de ejecución es NETWORK SERVICE, etc.Ahí está vacío→ «No se encuentra el certificado»Va al almacén de usuariode la cuenta del desarrolladorDoble clic en el pfx para importarloEl asistente usa «Usuario actual» por defectoSe ejecuta desde Visual Studio= corre con la cuenta del desarrolladorAl abrir CurrentUser lo encuentra→ Funciona

El punto clave es que el almacén de usuario «existe tantas veces como cuentas haya». Aunque un administrador abra certmgr.msc y compruebe «¿está bien instalado, no?», ese es su propio almacén, no el de la cuenta de servicio. La solución no es copiarlo de forma improvisada, sino volver a instalarlo en el almacén del equipo y alinear también el código con StoreLocation.LocalMachine. Y esto va unido a la concesión de permisos que se explica en el próximo capítulo.

4. La clave privada y los permisos de acceso — el segundo error clásico

4.1. El certificado y la clave privada son cosas distintas

Lo que se ve en el listado del almacén de certificados es el certificado (información pública), no la clave privada en sí. Lo que realmente hace falta en la autenticación de cliente es el proceso de firma con la clave privada, así que «aparecer en el listado» y «poder usarlo» son cuestiones distintas. Confundir esto produce fallos difíciles de diagnosticar a simple vista, del tipo «el certificado existe pero falla el protocolo de enlace TLS» o «aparece un error interno del tipo Access Denied».

4.2. La práctica de importar un pfx — la posibilidad de exportar es una decisión de diseño

El par formado por el certificado y la clave privada se entrega en un archivo pfx (PKCS #12), que se puede incorporar al almacén con Import-PfxCertificate. 6

$pwd = Get-Credential -UserName '(escriba la contraseña abajo)' -Message 'Contraseña del PFX'
Import-PfxCertificate -FilePath C:\certs\client.pfx `
    -CertStoreLocation Cert:\LocalMachine\My -Password $pwd.Password

Aquí lo importante es el comportamiento predeterminado: salvo que se indique -Exportable, la clave privada incorporada no se puede volver a exportar. 6 Importarlo todo como exportable «por si acaso hay que migrarlo después» añade una vía más para sacar la clave privada. Lo recomendable es conservar el pfx original en un lugar seguro y dejar que la clave privada del almacén sea, por defecto, no exportable; esa es nuestra recomendación. Dicho esto, precisamente el pfx original y su contraseña son lo que suele quedar abandonado en texto claro. El enfoque para evitarlo lo desarrollamos en «Almacenamiento de información confidencial en aplicaciones de Windows — evite la configuración en texto claro con DPAPI» y en «Manejo seguro de credenciales en PowerShell».

4.3. Conceder permiso sobre la clave privada a la cuenta de servicio

Lo habitual es que la clave privada de un certificado colocado en el almacén del equipo esté configurada, de forma predeterminada, para que nadie más que los administradores y SYSTEM puedan leerla. Por eso, un servicio que se ejecuta con LocalSystem puede leer la clave privada tal cual, pero si se ejecuta con cualquier otra cuenta —NETWORK SERVICE, una cuenta de servicio dedicada, la identidad de un grupo de aplicaciones de IIS, etc.—, hay que conceder explícitamente permiso de lectura a la cuenta de ejecución. El procedimiento se realiza desde la interfaz del complemento de certificados. 5

  1. Abra certlm.msc (o el complemento de certificados dirigido a la cuenta de equipo).
  2. En «Personal» → «Certificados», haga clic con el botón derecho en el certificado correspondiente y abra «Administrar claves privadas» desde «Todas las tareas».
  3. En la pestaña «Seguridad», agregue la cuenta de ejecución (NETWORK SERVICE, una cuenta de servicio dedicada, la identidad del grupo de aplicaciones de IIS, etc.) y conceda permiso de «Lectura». 5

No hace falta el control total: si solo se usa para firmar, basta con el permiso de lectura. Y a la inversa, conceder control total a Everyone porque «no funciona» reduce la clave privada al mismo nivel de protección que una contraseña en texto claro, así que evítelo por completo. Colocarlo en el almacén del equipo y conceder el permiso de la clave privada van siempre juntos: basta con dejarlo escrito en el procedimiento para que este tipo de incidente desaparezca.

5. Cómo prevenir incidentes por vencimiento — inventario, renovación y registro

5.1. Hacer el inventario con PowerShell

La fecha de vencimiento del certificado está en la propiedad NotAfter. Se puede hacer el inventario de forma mecánica con Get-ChildItem sobre la unidad Cert:. 4

# Enumera el almacén "Personal" del equipo ordenado por fecha de vencimiento
Get-ChildItem Cert:\LocalMachine\My |
    Sort-Object NotAfter |
    Format-Table Thumbprint, Subject, NotAfter

# Extrae solo los que vencen dentro de 60 días (con 0 se obtienen los ya vencidos)
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 60

-ExpiringInDays es un parámetro que devuelve «los certificados que vencen dentro del número de días indicado»; con 0 aparecen los ya vencidos. 4 Basta con convertir esto en una tarea programada mensual que recorra todos los servidores y reúna el resultado en un correo o en un registro, para prevenir casi por completo el incidente típico de «no se puede confirmar la elegibilidad desde el lunes por la mañana porque el certificado venció».

5.2. Procedimiento de renovación — el periodo de convivencia entre el certificado antiguo y el nuevo, y la trampa de la huella digital

Renovar un certificado no consiste en «eliminarlo e instalar el nuevo», sino en «agregarlo, cambiar, verificar y luego eliminar».

  1. Importe el certificado nuevo (pfx) en el mismo almacén. Como la huella digital es distinta, el antiguo y el nuevo pueden convivir en el mismo almacén.
  2. Conceda el permiso sobre la clave privada del certificado nuevo (capítulo 4). Esto es lo que se olvida con más facilidad al renovar. El permiso se asocia a la clave privada de cada certificado, así que al renovarlo hay que volver a concederlo.
  3. Si la API exige registro previo del certificado, notifique primero al sistema de la contraparte manteniendo la operación con el certificado antiguo, y asegure un periodo de convivencia en el que se acepten ambos. Si se hace el cambio antes, la contraparte rechazará el certificado nuevo y se detendrá la comunicación en producción.
  4. Cambie la configuración de la aplicación al certificado nuevo y verifique el funcionamiento.
  5. Transcurrido un periodo suficiente, elimine el certificado antiguo.
Procedimiento de renovación del certificadoMuestra los cinco pasos de la renovación, importar el pfx nuevo, conceder el permiso de la clave privada, registrar el certificado ante la contraparte, cambiar la configuración y verificar, y eliminar el certificado antiguo tras el periodo de convivencia1. Importar el pfx nuevoal mismo almacén (convivencia)2. Conceder el permisode clave privada del nuevo3. Registro previo ante la contraparte(seguir operando con el antiguo)4. Reescribir la huella digitalen la configuración y verificar5. Eliminar el certificado antiguotras el periodo de convivencia

La trampa mayor aquí es la huella digital escrita en archivos de configuración o en el código. Como la huella digital es única para cada certificado, siempre cambia al renovarlo. Si aunque sea en un solo lugar sigue apuntando a la huella antigua, ocurre «actualicé el certificado, pero no puedo conectarme». Lo más seguro es llevar en un registro dónde está escrita la huella digital (configuración de la aplicación, enlaces de IIS, scripts, notificación a la contraparte).

5.3. La recomendación de llevar un registro de certificados

Aunque se le llame «registro», basta al principio con una sola hoja de Excel. Como mínimo, cree columnas para uso / emisor / sujeto / huella digital / ubicación (nombre del servidor + almacén) / cuenta con permiso sobre la clave privada / fecha de vencimiento / enlace al procedimiento de renovación / responsable, y contrástelas con el resultado del inventario de 5.1. La naturaleza real de los incidentes con certificados no es un problema técnico, sino que «nadie tiene el listado», así que el registro es lo que más resultado da.

6. Verificación e interpretación de fallos — la cadena de certificación y la distribución de la raíz

6.1. Fundamentos de la verificación de la cadena y certutil

Los errores del tipo «este certificado no es de confianza» indican que la cadena (la ruta de certificación) desde el certificado final hasta la CA raíz está rota en algún punto. certutil es útil para aislar el problema. 7

Cadena de certificación y sus fallos habitualesMuestra la cadena desde el certificado final hasta la CA intermedia y la CA raíz, junto con los tres motivos habituales de fallo, la imposibilidad de construir la cadena, el error de no confianza y el error de vigenciaNo se puede obtener(ni por presentación, ni por AIA, ni del almacén)No está distribuidaVencidoCertificado final(cliente o servidor)Certificado de CA intermediaUbicación: almacén de entidades intermedias (CA)Certificado de CA raízUbicación: entidades raíz de confianza (Root)No se puede construir la cadena(causa habitual 1)Error «no es de confianza»(causa habitual 2)Error de periodo de vigencia(causa habitual 3) 
:: Construye y verifica la cadena del archivo de certificado (obteniendo también la URL de revocación)
certutil -urlfetch -verify client.cer

:: Si la aplicación en cuestión usa el almacén de usuario, añada -user para verificar en el mismo contexto
certutil -user -urlfetch -verify client.cer

:: Vuelca el contenido del almacén (con -user se vuelca el almacén de usuario)
certutil -store My
certutil -user -store My

certutil -verify verifica el certificado, la CRL y la cadena, y si no se indica CACertFile, construye y verifica la cadena completa. 7 La salida es extensa, pero permite leer en qué nivel se rompió la confianza y si se pudo obtener la información de revocación. Las causas típicas son tres: (1) no se puede obtener el certificado de la CA intermedia (el otro extremo TLS no lo envía, tampoco se puede obtener desde la información AIA del certificado, y tampoco está en el almacén «Entidades de certificación intermedias»); (2) la raíz de la CA interna no está distribuida en «Entidades de certificación raíz de confianza»; (3) el propio certificado ha vencido. Como la CA intermedia también se puede resolver mediante la presentación de la contraparte o la obtención automática vía AIA, entienda la colocación en el almacén como «una de las formas de asegurarlo», no la única.

6.2. Distribuya la raíz de una CA interna o de un certificado autofirmado mediante GPO/Intune

Si se usa una CA interna o un certificado autofirmado para pruebas, es necesario distribuir su certificado raíz a cada PC. En vez de instalarlo manualmente equipo por equipo, apóyese en un mecanismo de distribución.

  • Entorno de Active Directory (GPO): si importa el certificado en «Entidades de certificación raíz de confianza», dentro de Configuración del equipo\Directivas\Configuración de Windows\Configuración de seguridad\Directivas de clave pública de la directiva de grupo, se distribuye a los PC de destino. 8
  • Entorno administrado con Intune: el perfil «Certificado de confianza» distribuye el certificado de CA raíz o intermedia. En Windows se puede elegir el almacén de destino (raíz del equipo, intermedia del equipo, intermedia del usuario). 9

Como se explicó en 2.1, si se coloca en la raíz del almacén del equipo, queda de confianza para todos los usuarios. 1 Precisamente por eso, enfrente también el riesgo contrario. Colocar un certificado autofirmado en «Entidades de certificación raíz de confianza» equivale a plantar un nuevo punto de partida de confianza en ese PC. Si su clave privada se filtra, se convierte en la base para emitir certificados que suplanten a cualquier sitio o software. Si se busca una operación permanente, lo correcto es levantar una CA interna que proteja adecuadamente su clave privada, o inclinarse por certificados de una CA pública; para una raíz autofirmada, el principio es «solo en entorno de pruebas, y con fecha de caducidad».

7. La perspectiva del desarrollador — usar el almacén correctamente desde .NET

7.1. Buscar por huella digital con X509Store

Desde .NET se abre el almacén con X509Store y se obtiene el certificado con Find. 1011

using System.Security.Cryptography.X509Certificates;

static X509Certificate2 GetClientCertificate(string thumbprint)
{
    using var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
    store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);

    var found = store.Certificates.Find(
        X509FindType.FindByThumbprint, thumbprint, validOnly: true);

    if (found.Count == 0)
        throw new InvalidOperationException(
            $"No se encuentra el certificado: huella digital={thumbprint}, " +
            $"ubicación={store.Location}\{store.Name}");

    var cert = found[0];
    if (!cert.HasPrivateKey)
        throw new InvalidOperationException(
            $"El certificado existe pero no tiene una clave privada asociada " +
            $"(por ejemplo, se importó desde un .cer): huella digital={thumbprint}, ubicación={store.Location}\{store.Name}");

    return cert;
}

La decisión del capítulo 3 se traslada directamente aquí: StoreLocation.LocalMachine para código que corre en un servicio, StoreLocation.CurrentUser para una aplicación interactiva. Preste atención también al tercer argumento de Find, validOnly. true devuelve solo los certificados válidos que pasaron la verificación. 11 Esto actúa como seguro para no tomar un certificado vencido, pero también hace que un certificado autofirmado de pruebas, cuya cadena no es de confianza, caiga del lado de «no encontrado», así que sospeche también de esto cuando algo «está instalado pero no se encuentra». Además, como en el ejemplo anterior, incluya siempre en el mensaje de error de «no encontrado» qué almacén se buscó: el tiempo de investigación de los incidentes del capítulo 3 cambia en órdenes de magnitud.

7.2. Adjuntar el certificado de cliente a HttpClient

El certificado obtenido se agrega a HttpClientHandler.ClientCertificates para presentarlo al servidor. Esta colección es el conjunto de certificados que se presenta al servidor en la autenticación de cliente basada en certificados. 12

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(GetClientCertificate(thumbprint));

var client = new HttpClient(handler);
// A partir de aquí se usa como un HttpClient normal

Cabe señalar que, en las variantes de .NET Core, la documentación especifica explícitamente que, si el certificado tiene el atributo de uso de clave (Key Usage), este no se usa para enviar la solicitud a menos que incluya «Digital Signature». 12 Si le corresponde solicitar la emisión de un certificado de cliente, comunique correctamente su propósito (autenticación de cliente). Además, un patrón de creación equivocado de HttpClient provoca problemas de agotamiento de sockets y de seguimiento de DNS. El diseño de mantener el controlador con vida larga es el que se trató en «No envuelva HttpClient en un using».

7.3. El problema de que una huella digital fija en el código deje de funcionar tras la renovación

Buscar por huella digital es fiable, pero fijarla en el código exige compilar y publicar de nuevo en cada renovación del certificado. Las soluciones de diseño tienen tres niveles.

  • Nivel mínimo: externalice la huella digital a un archivo de configuración (appsettings, por ejemplo) para poder reemplazarla sin publicar de nuevo. Registre el lugar de configuración en el registro de 5.3.
  • Un paso más: busque por nombre de sujeto o emisor y combínelo con validOnly: true para elegir «el que tenga el NotAfter más lejano entre los actualmente válidos con ese nombre». Así se pasa automáticamente al certificado nuevo durante el periodo de convivencia. Sin embargo, existe el riesgo de tomar por error un certificado no deseado con el mismo nombre, así que combine esto con la verificación del emisor y con el registro en el log. Además, este cambio automático solo funciona cuando la contraparte no exige registro previo del certificado. En las API que sí lo exigen (5.2), el cambio automático podría pasar a un certificado que solo se importó pero no está registrado, deteniendo la comunicación; en ese caso, limítese al método de externalizar la configuración y cambiar solo después de confirmar que el registro se completó.
  • Cerrarlo con la operación: sea cual sea el método, deje registrado en el log, al iniciar, «qué certificado (huella digital, vencimiento) se eligió». Esa sola línea marca la diferencia tanto en la investigación de incidentes como en el contraste con el registro.

8. Relación con los certificados de firma de código — el almacén «Editores de confianza»

Hasta aquí se trataron los certificados para comunicaciones (TLS), pero en el almacén de certificados convive otro mundo: la firma de código. El almacén «Editores de confianza» (TrustedPublisher) que apareció en la tabla de 2.2 es el punto de contacto: es donde se registra como de confianza el certificado del editor de software firmado. Existe tanto en la ubicación de usuario como en la del equipo 10, y se usa, por ejemplo, para distribuir mediante GPO el editor de una aplicación interna al TrustedPublisher de cada PC.

Si usted es quien «distribuye» la aplicación y necesita lidiar con la firma de código o con la advertencia de SmartScreen («Windows protegió su PC»), lo hemos resumido en el artículo «Por qué aparece «Windows protegió su PC» en Windows». Los conocimientos de este artículo (los dos sistemas del almacén, la distribución de la raíz) sirven tal cual como base.

9. Resumen

  • El almacén de certificados tiene dos sistemas: usuario (CurrentUser) y equipo (LocalMachine). certmgr.msc, certlm.msc y la unidad Cert: son tres ventanas hacia lo mismo. El primer paso de cualquier investigación es alinear «de qué almacén se está hablando».
  • El lugar donde se coloca se decide según «como quién se ejecuta el programa». Como regla general, el almacén del equipo para la ejecución desatendida (servicio, IIS, tarea) y el almacén de usuario para las aplicaciones interactivas.
  • «Funcionaba en desarrollo pero no se encuentra en producción» se debe a que el almacén de usuario del desarrollador y el de la cuenta de servicio son cosas distintas. Se resuelve alineando todo con el almacén del equipo y StoreLocation.LocalMachine.
  • Colocarlo en el almacén del equipo y conceder el permiso de lectura desde «Administrar claves privadas» van siempre juntos. No olvide volver a concederlo al renovar.
  • La importación de pfx queda como no exportable por defecto. Use -Exportable solo cuando realmente sea necesario. Incluya en el diseño también la conservación del pfx original y su contraseña.
  • El vencimiento se previene con el inventario periódico de Get-ChildItem Cert: … -ExpiringInDays y con el registro de certificados. La renovación sigue el orden «agregar → cambiar → verificar → eliminar»; cuide no olvidar actualizar la huella digital en la configuración.
  • Para aislar problemas de la cadena, use certutil -urlfetch -verify. Distribuya la raíz de la CA interna mediante GPO/Intune, y limite la práctica de colocar un autofirmado en la raíz al entorno de pruebas y con fecha de caducidad.
  • En el código, externalice la huella digital a la configuración y deje registro en el log del certificado elegido. Solo con eso, la respuesta a incidentes por certificados cambia por completo.

Artículos relacionados

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del desarrollo de aplicaciones empresariales que integran conexiones a API web con certificado de cliente (API bancarias, confirmación de elegibilidad en línea, etc.), de la investigación de incidentes del tipo «no se encuentra el certificado» o «no se puede conectar tras la renovación», y de la elaboración de procedimientos para renovar certificados. Puede consultarnos incluso en la etapa en la que aún no sabe qué parte del almacén revisar.

Referencias

</content>

  1. Microsoft Learn, Local Machine and Current User Certificate Stores. Sobre que el almacén de certificados del equipo es local a ese PC y común a todos los usuarios, ubicado bajo HKEY_LOCAL_MACHINE; que el almacén del usuario es distinto para cada cuenta de usuario, ubicado bajo HKEY_CURRENT_USER; y que el almacén de usuario hereda el contenido del almacén del equipo salvo en el almacén «Personal» (un certificado agregado a «Entidades de certificación raíz de confianza» del equipo aparece también en el mismo almacén de cada usuario). ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, System Store Locations. Sobre las ubicaciones de registro de CERT_SYSTEM_STORE_CURRENT_USER / CERT_SYSTEM_STORE_LOCAL_MACHINE (respectivamente, Software\Microsoft\SystemCertificates bajo HKEY_CURRENT_USER / HKEY_LOCAL_MACHINE); que los almacenes lógicos predefinidos son MY, Root, Trust y CA; que el almacén de servicios reside en una clave de registro por cada nombre de servicio (Software\Microsoft\Cryptography\Services\ServiceName\SystemCertificates); y que existe además un almacén independiente para la distribución por directiva de grupo. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, How to: View certificates with the MMC snap-in. Sobre que certlm.msc administra los certificados del dispositivo local (equipo local) y certmgr.msc los del usuario actual; que el complemento de certificados admite tres tipos de destino, «cuenta de equipo», «cuenta de usuario» y «cuenta de servicio»; y que un usuario sin privilegios de administrador solo puede administrar los certificados de su propia cuenta de usuario. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, about_Certificate_Provider. Sobre que la unidad Cert: de PowerShell es un espacio de nombres jerárquico con dos ubicaciones de almacén, CurrentUser y LocalMachine; que Get-ChildItem permite enumerar almacenes y certificados; que el parámetro -ExpiringInDays devuelve los certificados que vencen dentro del número de días indicado (con 0, los ya vencidos); los parámetros dinámicos como -CodeSigningCert; que la propiedad NotAfter contiene la fecha de vencimiento; y que los certificados se identifican por su huella digital. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, How to Modify Private Key Permissions to Support Management Server or Streaming Server. Sobre el procedimiento para abrir «Administrar claves privadas» (Manage Private Keys) en el complemento de certificados dirigido al almacén del equipo local y agregar, en la pestaña «Seguridad», el permiso de acceso «Lectura» para la cuenta de ejecución del servicio (por ejemplo, Network Service). ↩ ↩2 ↩3

  6. Microsoft Learn, Import-PfxCertificate. Sobre que Import-PfxCertificate incorpora el certificado y la clave privada de un archivo PFX al almacén indicado; que sin el modificador -Exportable la clave privada incorporada no se puede exportar; y sobre la sintaxis y los ejemplos de uso de los parámetros -CertStoreLocation, -Password y -FilePath. ↩ ↩2 ↩3

  7. Microsoft Learn, certutil. Sobre que certutil -verify verifica el certificado, la CRL y la cadena de certificación, y que si no se indica el archivo de certificado de CA construye y verifica la cadena completa; que la opción -urlfetch está disponible; y que certutil -store vuelca el almacén de certificados, pudiendo acceder al almacén de usuario en lugar del de equipo con la opción -user. ↩ ↩2

  8. Microsoft Learn, Distribute Certificates to Client Computers by Using Group Policy. Sobre el procedimiento para importar un certificado en «Entidades de certificación raíz de confianza», dentro de «Configuración del equipo\Directivas\Configuración de Windows\Configuración de seguridad\Directivas de clave pública» de la directiva de grupo, y distribuirlo a los equipos cliente del dominio, junto con los permisos necesarios (equivalentes a Domain Admins / Enterprise Admins). ↩

  9. Microsoft Learn, Create trusted certificate profiles in Microsoft Intune. Sobre que el perfil «Certificado de confianza» de Intune es el mecanismo que distribuye un certificado de CA raíz o intermedia a los dispositivos administrados; que se usa para establecer la confianza en la CA raíz como requisito previo de los perfiles de certificado SCEP/PKCS; y que en Windows se puede elegir como almacén de destino «Almacén de certificados del equipo - Raíz», «Almacén de certificados del equipo - Intermedia» o «Almacén de certificados del usuario - Intermedia». ↩

  10. Microsoft Learn, X509Store Class. Sobre que X509Store se puede construir indicando StoreName y StoreLocation (CurrentUser / LocalMachine); que el almacén se abre con el método Open y OpenFlags (ReadOnly, OpenExistingOnly, etc.); que la propiedad Certificates permite obtener la colección de certificados; que los nombres de almacén estándar incluyen My, Root, CA, TrustedPublisher, etc.; y que el almacén TrustedPublisher existe tanto en CurrentUser como en LocalMachine. ↩ ↩2

  11. Microsoft Learn, X509Certificate2Collection.Find(X509FindType, Object, Boolean) Method. Sobre que el método Find busca certificados mediante un X509FindType (FindByThumbprint, etc.) y un valor de búsqueda, y que al indicar true en el tercer argumento validOnly solo se devuelven los certificados válidos que pasaron la verificación. ↩ ↩2

  12. Microsoft Learn, HttpClientHandler.ClientCertificates Property. Sobre que la propiedad ClientCertificates es la X509CertificateCollection que se presenta al servidor en la autenticación de cliente basada en certificados, y que en .NET Core, si el certificado tiene el atributo de uso de clave, este debe incluir «Digital Signature». ↩ ↩2

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿En qué se diferencian certmgr.msc y certlm.msc?
La diferencia está en el almacén al que apuntan. certmgr.msc abre el almacén de certificados del usuario que ha iniciado sesión (usuario actual, CurrentUser), mientras que certlm.msc abre el almacén de certificados del equipo (equipo local, LocalMachine). El almacén del equipo es común a todos los usuarios y servicios de ese PC, y administrarlo requiere privilegios de administrador. Un usuario sin privilegios de administrador solo puede administrar su propio almacén de usuario. En ambos casos, el contenido se organiza en almacenes lógicos como "Personal" o "Entidades de certificación raíz de confianza", y desde PowerShell se ve la misma estructura como Cert:\CurrentUser y Cert:\LocalMachine.
¿En qué almacén debe colocarse un certificado de cliente, en el de usuario o en el del equipo?
Se decide según "como quién" se ejecuta el programa que usa ese certificado. Para una aplicación de escritorio que inicia un usuario interactivo, lo habitual es el almacén de usuario de esa misma persona (Cert:\CurrentUser\My). Para un programa que se ejecuta de forma desatendida —un servicio de Windows, un grupo de aplicaciones de IIS o una tarea del Programador de tareas—, se coloca en el almacén del equipo (Cert:\LocalMachine\My) y se concede a la cuenta de ejecución permiso de lectura sobre la clave privada. Como el almacén de usuario es distinto para cada cuenta, un certificado que un desarrollador colocó en su propio almacén de usuario no es visible para un servicio que se ejecuta con otra cuenta. Este es el motivo típico del incidente "funcionaba en desarrollo, pero no aparece en producción".
Cuando un servicio de Windows no encuentra o no puede usar un certificado, ¿qué se debe comprobar?
La comprobación tiene dos pasos. Primero, "qué almacén se está mirando": si el código abre StoreLocation.CurrentUser, ese es el almacén de usuario de la cuenta con la que se ejecuta el servicio, distinto del almacén que ve un administrador en certmgr.msc. Traslade el certificado al almacén del equipo y ajuste también el código a StoreLocation.LocalMachine. Segundo, "si se puede leer la clave privada": que el certificado aparezca en la lista no significa que se pueda usar su clave privada, y lo habitual es que, de forma predeterminada, la clave privada del almacén del equipo solo sea accesible para los administradores y SYSTEM. Abra "Administrar claves privadas" sobre el certificado correspondiente desde certlm.msc y conceda permiso de "Lectura" a la cuenta de ejecución del servicio (NETWORK SERVICE, por ejemplo).
¿Cómo detectar con antelación, mediante PowerShell, los certificados a punto de vencer?
Se puede hacer el inventario con Get-ChildItem sobre la unidad Cert:. Por ejemplo, Get-ChildItem Cert:\LocalMachine\My | Sort-Object NotAfter | Format-Table Thumbprint, Subject, NotAfter permite listar el almacén "Personal" del equipo ordenado por fecha de vencimiento. Además, el parámetro -ExpiringInDays permite extraer solo los "certificados que vencen dentro del número de días indicado"; si se indica 0, se obtienen los que ya han vencido. Ejecutando esto mensualmente en todos los servidores y contrastando el resultado con el registro de certificados, se evita casi por completo el incidente típico de "no se puede conectar desde primera hora de la mañana por un certificado vencido".

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog