¿Qué certificado SSL admitiría nombres de dominio internos y externos?

¿Qué certificado SSL admitiría nombres de dominio internos y externos?

Esta es una red escolar.

Oficial (nombre de dominio externo accesible) es bgschwechat.ac.at (www.bgschwechat..., mail.bgschwechat... y ftp.bgschwechat...)

Internamente el dominio de Windows se llama bgs.ac.at

Necesitamos certificados SSL (posiblemente económicos) para servidor web y servidor Exchange

Desde nuestro firewall (www.bgschwechat.ac.at) (Sophos UTM9), las solicitudes se conectan mediante NAT a máquinas virtuales; algunas de ellas necesitan SSL

  • Servidor web (ejecutando CENTOS - www.bgschwechat.ac.at)
  • Se debe poder acceder al servidor Exchange (llamado xch.bgs.ac.at) a través de NAT como mail.bgschwechat.ac.at
  • Servidor WSUS (dc2.bgs.ac.at): solo para clientes internos

Mi pregunta: ¿Qué tipo de certificado SSL necesitaríamos para proteger, por ejemplo? ¿Ambos dominios (bgschwechat.ac.at Y bgs.ac.at) para que parezcan protegidos desde el exterior cuando se hace NATTING, por ejemplo, mail.bgschwechat.ac.at a xch.bgs.ac.at?

¿O necesitamos cambiar el nombre del dominio interior al nombre de dominio oficial?

...recomendaciones ¿dónde adquirir dicho certificado?

Respuesta1

Supongo que no obtendrá un certificado comodín para *.ac.at aquí;)

Un certificado con ambos nombres de dominio se llamacertificado multidominio, en tu caso bgs.ac.aty bgschwechat.ac.at. Además necesitascertificados comodínPara *.bgs.ac.aty *.bgschwechat.ac.at. Todos los nombres pueden estar en un certificado usandoNombres alternativos del sujeto.

Puede generar dicho certificado con OpenSSL usando un archivo de configuración:

openssl req -new -out bgschwechat.ac.at.csr -key bgschwechat.ac.at.key -config bgschwechat.ac.at.cnf

utilizando una clave existente bgschwechat.ac.at.keygenerada por

openssl genrsa 4096 -out bgschwechat.ac.at.key

y usando lo siguiente bgschwechat.ac.at.cnf:

[req]
distinguished_name = req_distinguished_name
default_bits           = 4096
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = bgschwechat.ac.at
DNS.2 = *.bgschwechat.ac.at
DNS.3 = bgs.ac.at
DNS.4 = *.bgs.ac.at

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
organizationalUnitName  = Organizational Unit Name (eg, section)
countryName_default = AT
stateOrProvinceName_default = Niederoesterreich
localityName_default = Schwechat
organizationalUnitName_default = BG Schwechat
commonName = Common Name (CN)
commonName_default = bgschwechat.ac.at
emailAddress_default = [email protected]

Aquí tienes que pagar por 2 certificados de dominio simples, más 2 comodines. Por lo tanto, definitivamente es más económico cambiar el nombre del dominio utilizado internamente (o redirigirlo mediante HTTP). En lugar de los comodines, también puedes agregar todos los subdominios (correo, www, etc.) a la lista de dominios alternativos.

Si no desea proteger sus dominios internos bgs.ac.at, puede omitirlo.


en¿Sólo direcciones "externas que se pueden resolver"?: Cada CA puede definir sus propias reglas. En la mayoría de los casos es una cuestión de dinero, como siempre ocurre con las CA. Por lo general, las CA no emiten certificados para direcciones que no se pueden resolver (solo si paga más). Como bgs.ac.at no se puede resolver, no obtendrá un certificado tan fácilmente. Si solo se usa internamente, también puede emitir un certificado autofirmado e implementarlo en cada computadora.

Las recomendaciones sobre dónde comprar algo sonfuera de contextoen Serverfault.

información relacionada