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.
Azure Stack Hub tiene una red de infraestructura pública mediante direcciones IP públicas accesibles externamente asignadas a un pequeño conjunto de servicios de Azure Stack Hub y, posiblemente, máquinas virtuales de inquilino. Los certificados PKI con los nombres DNS adecuados para estos puntos de conexión de infraestructura pública de Azure Stack Hub se requieren durante la implementación de Azure Stack Hub. En este artículo se proporciona información acerca de lo siguiente:
- Requisitos de certificado para Azure Stack Hub.
- Certificados obligatorios necesarios para la implementación de Azure Stack Hub.
- Certificados opcionales requeridos al implementar proveedores de recursos de valor añadido.
Nota:
De forma predeterminada, Azure Stack Hub también usa certificados emitidos desde una entidad de certificación (CA) integrada interna de Active Directory para la autenticación entre los nodos. Para validar el certificado, todas las máquinas de infraestructura de Azure Stack Hub confían en el certificado raíz de la entidad de certificación interna agregando ese certificado a su almacén de certificados local. No hay anclaje ni filtrado de certificados en Azure Stack Hub. El nombre alternativo del firmante de cada certificado de servidor se valida en el nombre de dominio completo del destino. La cadena de confianza completa también se valida, junto con la fecha de expiración del certificado (autenticación estándar del servidor TLS sin anclaje de certificados).
Requisitos de certificados
En la lista siguiente se describen los requisitos generales de emisión, seguridad y formato de certificados:
- Los certificados deben emitirse desde una entidad de certificación interna o pública. Si se usa una entidad de certificación pública, debe incluirse en la imagen de sistema operativo base como parte del Programa de entidades raíz de confianza de Microsoft. Para ver la lista completa, consulte Lista de participantes: Programa de certificados raíz de confianza de Microsoft.
- La infraestructura de Azure Stack Hub debe tener acceso de red a la ubicación de la lista de revocación de certificados (CRL) de la entidad de certificación publicada en el certificado. Esta lista de revocación de certificados debe ser un punto de conexión HTTP. En el caso de las implementaciones desconectadas, si el punto de conexión crL no es accesible, no se admiten certificados emitidos por una entidad de certificación pública (CA). Para obtener más información, consulte Características que están afectadas o que no están disponibles en implementaciones desconectadas.
- Al rotar certificados en compilaciones anteriores a la versión 1903, los certificados deben ser emitidos por la misma autoridad de certificación interna que se utiliza para firmar certificados durante el despliegue, o por cualquier autoridad de certificación pública mencionada anteriormente.
- En la rotación de certificados para la versión 1903 y posteriores, cualquier entidad de certificación pública o empresa puede emitir los certificados.
- No se admiten certificados autofirmados.
- En el caso de la implementación y rotación, puede usar un certificado único que abarque todos los espacios de nombres en el nombre del firmante y el nombre alternativo del firmante (SAN) del certificado. Como alternativa, puede usar certificados individuales para cada uno de los espacios de nombres siguientes que los servicios de Azure Stack Hub que planea usar requieren. Para ambos enfoques hay que usar caracteres comodín para los puntos de conexión donde sean necesarios, como KeyVault y KeyVaultInternal.
- El algoritmo de firma de certificado no debe ser SHA1.
- El formato de certificado debe ser PFX, ya que las claves públicas y privadas son necesarias para la instalación de Azure Stack Hub. La clave privada debe tener establecido el atributo de clave de la máquina local.
- El cifrado PFX debe ser 3DES (este cifrado es predeterminado al exportar desde un cliente de Windows 10 o un almacén de certificados de Windows Server 2016).
- Los archivos pfx de certificado deben tener un valor "Firma digital" y "KeyEncipherment" en su campo "Uso de claves".
- Los archivos pfx de certificado deben tener los valores "Autenticación del servidor (1.3.6.1.5.5.7.3.1)" en el campo "Uso mejorado de claves".
- El campo "Emitido a:" del certificado no debe ser el mismo que el campo "Emitido por:".
- Las contraseñas de todos los archivos pfx de certificado deben ser las mismas en el momento de la implementación.
- La contraseña del certificado pfx debe ser una contraseña compleja. Tome nota de esta contraseña, ya que la usa como parámetro de implementación. La contraseña debe cumplir los siguientes requisitos de complejidad de contraseña:
- Longitud mínima de ocho caracteres.
- Al menos tres de los siguientes caracteres: letra mayúscula, letra minúscula, números de 0 a 9, caracteres especiales, caracteres alfabéticos que no están en mayúsculas o minúsculas.
- Asegúrese de que los nombres de los firmantes y los nombres alternativos de los firmantes de la extensión de nombre alternativo del firmante (x509v3_config) coinciden. El campo nombre alternativo del firmante permite especificar nombres de host adicionales (sitios web, direcciones IP, nombres comunes) que se van a proteger mediante un único certificado SSL.
Nota:
No se admiten certificados autofirmados.
Al implementar Azure Stack Hub en modo desconectado, se recomienda usar certificados emitidos por una entidad de certificación de empresa. Esto es importante porque los clientes que acceden a los puntos de conexión de Azure Stack Hub deben poder ponerse en contacto con la lista de revocación de certificados (CRL).
Nota:
Se admite la presencia de entidades de certificación intermedias en la cadena de confianzas de un certificado.
Certificados obligatorios
En la tabla de esta sección se describen los certificados PKI de punto de conexión público de Azure Stack Hub que son necesarios para las implementaciones de Microsoft Entra ID y AD FS de Azure Stack Hub. Los requisitos de certificado se agrupan por área y los espacios de nombres usados y los certificados necesarios para cada espacio de nombres. En la tabla también se describe la carpeta en la que el proveedor de soluciones copia los distintos certificados por punto de conexión público.
Se requieren certificados con los nombres DNS apropiados para cada punto de conexión de la infraestructura pública de Azure Stack Hub. El nombre DNS de cada punto de conexión se expresa en el formato <prefix>.<region>.<fqdn>.
Para su implementación, los valores <region> y <fqdn> deben coincidir con los nombres de región y de dominio externo que eligió para su sistema de Azure Stack Hub. Por ejemplo, si la región es Redmond y el nombre de dominio externo es contoso.com, los nombres DNS tienen el formato <prefix>.redmond.contoso.com. Los valores <prefix> son reservados por Microsoft para describir el punto de conexión asegurado por el certificado. Además, los <prefix> valores de los puntos de conexión de infraestructura externa dependen del servicio de Azure Stack Hub que use el punto de conexión específico.
En entornos de producción, se recomienda generar certificados individuales para cada punto de conexión y copiarlos en el directorio correspondiente. Para los entornos de desarrollo, los certificados se pueden proporcionar como un certificado comodín único que abarque todos los espacios de nombres en los campos de Sujeto y Nombre alternativo del sujeto (SAN) y que se copie en todos los directorios. Un único certificado que cubre todos los puntos de conexión y servicios es una posición no segura y, por lo tanto, solo está pensado para el desarrollo. Recuerde que ambas opciones requieren que use certificados comodín para puntos de conexión como acs y Key Vault en los que sean necesarios.
Nota:
Durante la implementación, debe copiar certificados en la carpeta de implementación que coincida con el proveedor de identidades en el que se va a implementar (Id. de Microsoft Entra o AD FS). Si usa un único certificado para todos los puntos de conexión, debe copiar ese archivo de certificado en cada carpeta de implementación, como se describe en las tablas siguientes. La estructura de carpetas está precompilada en la máquina virtual de implementación y se puede encontrar en C:\CloudDeployment\Setup\Certificates.
| Carpeta de implementación | Nombres alternativos del firmante (SAN) y firmante del certificado requeridos | Ámbito (por región) | Espacio de nombres de subdominio |
|---|---|---|---|
| Portal público | portal.<region>.<fqdn> |
Portales | <region>.<fqdn> |
| Portal de administración | adminportal.<region>.<fqdn> |
Portales | <region>.<fqdn> |
| Azure Resource Manager Público | management.<region>.<fqdn> |
Azure Resource Manager | <region>.<fqdn> |
| Administrador de Azure Resource Manager | adminmanagement.<region>.<fqdn> |
Azure Resource Manager | <region>.<fqdn> |
| ACSBlob | *.blob.<region>.<fqdn>(Certificado SSL comodín) |
Blob Storage | blob.<region>.<fqdn> |
| ACSTable | *.table.<region>.<fqdn>(Certificado SSL comodín) |
Almacenamiento de tablas | table.<region>.<fqdn> |
| ACSQueue | *.queue.<region>.<fqdn>(Certificado SSL comodín) |
Almacenamiento en cola | queue.<region>.<fqdn> |
| KeyVault | *.vault.<region>.<fqdn>(Certificado SSL comodín) |
Bóveda de claves | vault.<region>.<fqdn> |
| KeyVaultInternal | *.adminvault.<region>.<fqdn>(Certificado SSL comodín) |
Almacén de claves interno | adminvault.<region>.<fqdn> |
| Host de extensiones de administración |
*.adminhosting.<region>.<fqdn> (Certificados SSL comodín) |
Host de extensión de administrador | adminhosting.<region>.<fqdn> |
| Host de extensiones públicas |
*.hosting.<region>.<fqdn> (Certificados SSL comodín) |
Host de extensión pública | hosting.<region>.<fqdn> |
Si implementa Azure Stack Hub mediante el modo de implementación de Microsoft Entra, solo tiene que solicitar los certificados enumerados en la tabla anterior. Si implementa Azure Stack Hub mediante el modo de implementación de AD FS, también debe solicitar los certificados descritos en la tabla siguiente:
| Carpeta de implementación | Nombres alternativos del firmante (SAN) y firmante del certificado requeridos | Ámbito (por región) | Espacio de nombres de subdominio |
|---|---|---|---|
| ADFS | adfs.<region>.<fqdn>(certificado SSL) |
AD FS | <region>.<fqdn> |
| Gráfico | graph.<region>.<fqdn>(certificado SSL) |
Gráfico | <region>.<fqdn> |
Importante
Todos los certificados enumerados en esta sección deben tener la misma contraseña.
Certificados PaaS opcionales
Si tiene previsto implementar servicios PaaS de Azure Stack Hub (como SQL, MySQL, App Service o Event Hubs) después de implementar y configurar Azure Stack Hub, debe solicitar certificados adicionales para cubrir los puntos de conexión de los servicios PaaS.
Importante
Los certificados que use para los proveedores de recursos deben tener la misma entidad raíz que las usadas para los puntos de conexión globales de Azure Stack Hub.
En la tabla siguiente se describen los puntos de conexión y los certificados necesarios para los proveedores de recursos. No es necesario copiar estos certificados en la carpeta de implementación de Azure Stack Hub. En su lugar, debe proporcionar estos certificados durante la instalación del proveedor de recursos:
| Ámbito (por región) | Certificado | Sujeto del certificado requerido y Nombres Alternativos de Asunto (SAN) | Espacio de nombres de subdominio |
|---|---|---|---|
| Servicio de Aplicaciones | Certificado SSL predeterminado del tráfico web | *.appservice.<region>.<fqdn>*.scm.appservice.<region>.<fqdn>*.sso.appservice.<region>.<fqdn>(Certificado SSL comodín de varios dominios1) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Servicio de Aplicaciones | Interfaz de Programación de Aplicaciones (API) | api.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Servicio de Aplicaciones | FTP | ftp.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Servicio de Aplicaciones | SSO | sso.appservice.<region>.<fqdn>(Certificado SSL2) |
appservice.<region>.<fqdn>scm.appservice.<region>.<fqdn> |
| Event Hubs | SSL | *.eventhub.<region>.<fqdn>(Certificado SSL comodín) |
eventhub.<region>.<fqdn> |
| SQL, MySQL | SQL y MySQL | *.dbadapter.<region>.<fqdn>(Certificado SSL comodín) |
dbadapter.<region>.<fqdn> |
1 Requiere un certificado con varios nombres alternativos de firmante comodín. Es posible que no todas las entidades de certificación públicas admitan varios SAN comodín en un único certificado.
2*.appservice.<region>.<fqdn>No se puede usar un certificado comodín en lugar de estos tres certificados (api.appservice.<region>.<fqdn>, ftp.appservice.<region>.<fqdn>, y sso.appservice.<region>.<fqdn>). Appservice requiere explícitamente el uso de certificados independientes para estos puntos de conexión.
Pasos siguientes
Aprenda a generar certificados PKI para la implementación de Azure Stack Hub.