Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Para programar la seguridad de Windows Communication Foundation (WCF), los certificados digitales X.509 se usan normalmente para autenticar clientes y servidores, cifrar y firmar mensajes digitalmente. En este tema se explican brevemente las características del certificado digital X.509 y cómo usarlas en WCF, e incluye vínculos a temas que explican estos conceptos más allá o que muestran cómo realizar tareas comunes mediante WCF y certificados.
En resumen, un certificado digital forma parte de una infraestructura de clave pública (PKI), que es un sistema de certificados digitales, entidades de certificación y otras entidades de registro que comprueban y autentican la validez de cada parte implicada en una transacción electrónica mediante el uso de criptografía de clave pública. Una entidad de certificación emite certificados y cada certificado tiene un conjunto de campos que contienen datos, como asunto (la entidad a la que se emite el certificado), fechas de validez (cuando el certificado es válido), emisor (la entidad que emitió el certificado) y una clave pública. En WCF, cada una de estas propiedades se procesa como Claim, y cada reclamación se divide en dos tipos: identidad y derecho. Para obtener más información sobre los certificados X.509, consulte Certificados de clave pública X.509. Para obtener más información sobre las notificaciones y la autorización en WCF, vea Administración de notificaciones y autorización con el modelo de identidad. Para obtener más información sobre la implementación de una PKI, consulte Enterprise PKI with Windows Server 2012 R2 Active Directory Certificate Services (PKI empresarial con Windows Server 2012 R2 Active Directory Certificate Services).
La función principal de un certificado es autenticar la identidad del propietario del certificado en otros usuarios. Un certificado contiene la clave pública del propietario, mientras que el propietario conserva la clave privada. La clave pública se puede usar para cifrar los mensajes enviados al propietario del certificado. Solo el propietario tiene acceso a la clave privada, por lo que solo el propietario puede descifrar esos mensajes.
Los certificados deben ser emitidos por una entidad de certificación, que a menudo es un emisor de certificados de terceros. En un dominio de Windows, se incluye una entidad de certificación que se puede usar para emitir certificados a los equipos del dominio.
Ver certificados
Para trabajar con certificados, a menudo es necesario verlos y examinar sus propiedades. Esto se hace con facilidad con la herramienta de complemento Microsoft Management Console (MMC). Para obtener más información, vea Cómo: Ver certificados con el complemento MMC.
Almacenes de certificados
Los certificados se encuentran en almacenes. Existen dos ubicaciones principales de tiendas que se dividen aún más en sub-almacenes. Si es el administrador en un equipo, puede ver ambos almacenes principales utilizando la herramienta de complemento MMC. Los no administradores solo pueden ver el repositorio de usuarios actual.
Almacén del equipo local. Contiene los certificados a los que acceden los procesos de máquina, como ASP.NET. Use esta ubicación para almacenar certificados que autentiquen el servidor en los clientes.
El almacén del usuario actual. Las aplicaciones interactivas suelen colocar certificados aquí para el usuario actual del equipo. Si va a crear una aplicación cliente, es donde normalmente coloca certificados que autentican a un usuario en un servicio.
Estas dos tiendas se dividen aún más en sub-almacenes. Lo más importante de esto al programar con WCF incluye:
Entidades de certificación raíz de confianza. Puede usar los certificados de este almacén para crear una cadena de certificados, que se puede rastrear hasta un certificado de autoridad de certificación en este almacén.
Importante
El equipo local confía implícitamente en cualquier certificado colocado en este almacén, incluso si el certificado no procede de una entidad de certificación de terceros de confianza. Por este motivo, no coloque ningún certificado en este almacén a menos que confíe plenamente en el emisor y comprenda las consecuencias.
Personal. Este almacén se utiliza para los certificados asociados a un usuario de un equipo. Normalmente este almacén se usa para los certificados emitidos por uno de los certificados de la entidad de certificación situado en el almacén de las Entidades emisoras de certificados raíz de confianza. O bien, una aplicación puede confiar en un certificado que se encuentre aquí y que sea de emisión propia.
Para obtener más información sobre los almacenes de certificados, vea Almacenes de certificados.
Selección de una tienda
Seleccionar dónde almacenar un certificado depende de cómo y cuándo se ejecuta el servicio o el cliente. Se aplican las siguientes reglas generales:
Si el servicio WCF se hospeda en un servicio Windows, use el almacén del equipo local. Tenga en cuenta que se requieren privilegios de administrador para instalar certificados en el almacén de máquinas locales.
Si el servicio o el cliente es una aplicación que se ejecuta en una cuenta de usuario, use el almacén del usuario actual.
Acceso a tiendas
Las tiendas están protegidas por listas de control de acceso (ACL), al igual que las carpetas de un equipo. Al crear un servicio hospedado por Internet Information Services (IIS), el proceso de ASP.NET se ejecuta en la cuenta de ASP.NET. Esa cuenta debe tener acceso al almacén que contiene los certificados que usa un servicio. Cada uno de los almacenes principales está protegido con una lista de acceso predeterminada, pero se pueden modificar las listas. Si crea un rol separado para acceder a una tienda, debe otorgar a ese rol el permiso de acceso. Para obtener información sobre cómo modificar la lista de acceso mediante la herramienta de WinHttpCertConfig.exe, consulte How to: Create Temporary Certificates for Use During Development (Cómo: Crear certificados temporales para su uso durante el desarrollo).
Confianza de la cadena y entidades de certificación
Los certificados se crean en una jerarquía en la que cada certificado individual está vinculado a la ENTIDAD de certificación que emitió el certificado. Este enlace es al certificado de la entidad de certificación. A continuación, el certificado de la CA se vincula a la CA que emitió el certificado original de la CA. Este proceso se repite hasta que se alcanza el certificado de la Autoridad de Certificación Raíz. El certificado de la entidad de certificación raíz es de confianza inherente.
Los certificados digitales se usan para autenticar una entidad basándose en esta jerarquía, también denominada cadena de confianza. Puede ver cualquier cadena de certificados mediante el complemento MMC haciendo doble clic en cualquier certificado y, a continuación, haciendo clic en la pestaña Ruta de acceso del certificado. Para obtener más información sobre cómo importar cadenas de certificados para una entidad de certificación, vea Cómo: Especificar la cadena de certificados de la autoridad certificadora utilizada para verificar firmas.
Nota:
Cualquier emisor se puede designar como una entidad raíz de confianza colocando el certificado del emisor en el almacén de certificados de la entidad raíz de confianza.
Deshabilitación de la confianza en la cadena
Al crear un nuevo servicio, es posible que esté usando un certificado que no sea emitido por un certificado raíz de confianza o que el propio certificado emisor no esté en el almacén de entidades de certificación raíz de confianza. Solo con fines de desarrollo, puede deshabilitar temporalmente el mecanismo que comprueba la cadena de confianza de un certificado. Para ello, establezca la CertificateValidationMode propiedad en PeerTrust o PeerOrChainTrust. Cualquiera de los modos especifica que el certificado puede emitirse automáticamente (confianza del mismo nivel) o formar parte de una cadena de confianza. Puede establecer la propiedad en cualquiera de las clases siguientes.
También puede establecer la propiedad mediante configuración. Los siguientes elementos se usan para especificar el modo de validación:
Autenticación personalizada
La CertificateValidationMode propiedad también le permite personalizar cómo se autentican los certificados. De forma predeterminada, el nivel se establece en ChainTrust. Para utilizar el valor Custom, también debe establecer el atributo CustomCertificateValidatorType en un ensamblado y tipo utilizado para validar el certificado. Para crear un validador personalizado, debe heredar de la clase abstracta X509CertificateValidator .
Al crear un autenticador personalizado, el método más importante para invalidar es el Validate método . Para obtener un ejemplo de autenticación personalizada, consulte el ejemplo de validador de certificado X.509 . Para obtener más información, consulte Validación de credenciales y credenciales personalizadas.
Uso del cmdlet New-SelfSignedCertificate de PowerShell para crear una cadena de certificados
El cmdlet New-SelfSignedCertificate de PowerShell crea certificados X.509 y pares de claves privadas o clave pública. Puede guardar la clave privada en el disco y, a continuación, usarla para emitir y firmar nuevos certificados, simulando así una jerarquía de certificados encadenados. El cmdlet está pensado para su uso solo como ayuda al desarrollar servicios y nunca debe usarse para crear certificados para la implementación real. Al desarrollar un servicio WCF, siga estos pasos para crear una cadena de confianza con el cmdlet New-SelfSignedCertificate.
Cree un certificado de entidad raíz temporal (autofirmado) mediante el cmdlet New-SelfSignedCertificate. Guarde la clave privada en el disco.
Use el nuevo certificado para emitir otro certificado que contenga la clave pública.
Importe el certificado de la entidad emisora raíz en el almacén Entidades emisoras de certificados raíz de confianza.
Para obtener instrucciones paso a paso, vea Cómo: Crear certificados temporales para su uso durante el desarrollo.
¿Qué certificado se va a usar?
Las preguntas comunes sobre los certificados son qué certificado se va a usar y por qué. La respuesta depende de si está programando un cliente o servicio. La siguiente información proporciona una guía general y no es una respuesta exhaustiva a estas preguntas.
Certificados de servicio
Los certificados de servicio tienen la tarea principal de autenticar el servidor en los clientes. Una de las comprobaciones iniciales cuando un cliente autentica un servidor es comparar el valor del campo Asunto con el identificador uniforme de recursos (URI) usado para ponerse en contacto con el servicio: el DNS de ambos debe coincidir. Por ejemplo, si el URI del servicio es http://www.contoso.com/endpoint/ el campo Asunto también debe contener el valor www.contoso.com.
Tenga en cuenta que el campo puede contener varios valores, cada uno con un prefijo con una inicialización para indicar el valor. Normalmente, la inicialización es "CN" para el nombre común, por ejemplo, CN = www.contoso.com. También es posible que el campo Asunto esté en blanco, en cuyo caso el campo Nombre alternativo del firmante puede contener el valor nombre DNS .
Tenga en cuenta también el valor del campo Propósitos previstos del certificado debe incluir un valor adecuado, como "Autenticación de servidor" o "Autenticación de cliente".
Certificados de cliente
Los certificados de cliente no suelen ser emitidos por una entidad de certificación de terceros. En su lugar, el almacén Personal de la ubicación del usuario actual normalmente contiene certificados colocados allí por una entidad raíz, con un propósito previsto de "Autenticación de cliente". El cliente puede usar este certificado cuando se requiere autenticación mutua.
Revocación en línea y revocación sin conexión
Validez del certificado
Cada certificado solo es válido durante un período de tiempo determinado, denominado período de validez. El período de validez se define mediante los campos Válido de y Válido a de un certificado X.509. Durante la autenticación, el certificado se comprueba para determinar si el certificado todavía está dentro del período de validez.
Lista de revocación de certificados
En cualquier momento durante el período de validez, la entidad de certificación puede revocar un certificado. Esto puede producirse por muchas razones, como que la clave privada del certificado esté en peligro.
Cuando esto ocurre, las cadenas que descienden del certificado revocado tampoco son válidas y no son de confianza durante los procedimientos de autenticación. Para averiguar qué certificados se revocan, cada emisor publica una lista de revocación de certificados con marca de fecha y hora (CRL). La lista se puede comprobar utilizando revocación en línea o sin conexión estableciendo la propiedad RevocationMode o DefaultRevocationMode de las siguientes clases en uno de los valores de enumeración X509RevocationMode : X509ClientCertificateAuthentication, X509PeerCertificateAuthentication, X509ServiceCertificateAuthentication, y las clases IssuedTokenServiceCredential. El valor predeterminado de todas las propiedades es Online.
También se puede establecer el modo de configuración con el atributo revocationMode de la <autenticación> (de <serviceBehaviors>) y la <autenticación> (de <endpointBehaviors>).
Método SetCertificate
En WCF, a menudo debe especificar un certificado o un conjunto de certificados que un servicio o cliente use para autenticar, cifrar o firmar digitalmente un mensaje. Puede hacerlo mediante programación mediante el SetCertificate método de varias clases que representan certificados X.509. Las siguientes clases usan el SetCertificate método para especificar un certificado.
El método SetCertificate funciona designando una ubicación del almacén y almacén, un tipo de "búsqueda” (parámetrox509FindType) que especifica un campo del certificado, y un valor para encontrar en el campo. Por ejemplo, el código siguiente crea una ServiceHost instancia y establece el certificado de servicio que se usa para autenticar el servicio en los clientes con el SetCertificate método .
Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
Varios certificados con el mismo valor
Un almacén puede contener varios certificados con el mismo nombre de firmante. Esto significa que si especifica que x509FindType es FindBySubjectName o FindBySubjectDistinguishedName, y más de un certificado tiene el mismo valor, se produce una excepción porque no hay ninguna manera de distinguir qué certificado es necesario. Puede mitigar esto configurando el x509FindType a FindByThumbprint. El campo huella digital contiene un valor único que se puede usar para buscar un certificado específico en un almacén. Sin embargo, esto tiene su propia desventaja: si el certificado se revoca o renueva, se produce un error en el SetCertificate método porque la huella digital también ha desaparecido. O bien, si el certificado ya no es válido, se produce un error en la autenticación. La manera de mitigar esto es establecer el parámetro x590FindType en FindByIssuerName y especificar el nombre del emisor. Si no se requiere ningún emisor determinado, también puede establecer uno de los otros X509FindType valores de enumeración, como FindByTimeValid.
Certificados en configuración
También puede establecer certificados mediante la configuración. Si va a crear un servicio, las credenciales, incluidos los certificados, se especifican en serviceBehaviors<>. Cuando programa un cliente, los certificados se especifican en endpointBehaviors<>.
Asignación de un certificado a una cuenta de usuario
Una característica de IIS y Active Directory es la capacidad de asignar un certificado a una cuenta de usuario de Windows. Para obtener más información sobre la característica, consulte Asignación de certificados a cuentas de usuario.
Para obtener más información sobre el uso de la asignación de Active Directory, vea Mapping Client Certificates with Directory Service Mapping (Asignación de certificados de cliente mediante la asignación del servicio de directorio).
Con esta funcionalidad habilitada, puede establecer la MapClientCertificateToWindowsAccount propiedad de la X509ClientCertificateAuthentication clase en true. En la configuración, se puede establecer el atributo mapClientCertificateToWindowsAccount del elemento de <autenticación> en true, como se muestra en el código siguiente.
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
La asignación de un certificado X.509 al token que representa una cuenta de usuario de Windows se considera una elevación de privilegios porque, una vez asignado, el token de Windows se puede usar para obtener acceso a los recursos protegidos. Por consiguiente, la directiva de dominio requiere que el certificado X.509 cumpla con su directiva antes de realizar la asignación. El paquete de seguridad de SChannel exige este requisito.
Cuando se usa .NET Framework 3.5 o versiones posteriores, WCF garantiza que el certificado se ajusta a la directiva de dominio antes de que se asigne a una cuenta de Windows.
En la primera versión de WCF, la asignación se realiza sin consultar la directiva de dominio. Por consiguiente, es posible que las aplicaciones anteriores que solían funcionar al ejecutarse bajo la primera publicación, provoquen un error si se habilita la asignación y el certificado X.509 no cumple la directiva de dominio.