Documentación Roots

SSL/TLS

HTTPS es más importante que nunca. Una encriptación sólida a través de HTTSP crea una web más segura y protege a los usuarios de tu sitio.

Roots se preocupa por la seguridad por lo que siempre ha hecho de SSL/HTTPS una prioridad en Trellis. Nuestra implementación está diseñada para marcar un A+ en las pruebas Qualy SSL Labs.

En el pasado, mucha gente evitaba moverse a HTTPS por razones técnicas y de conveniencia.

  • Los certificados eran costosos.
  • La configuración del web-server era compleja.
  • Los sitios en HTTPS eran mucho más lentos que los HTTP.

Trellis tiene características que hacen que usar HTTPS sea sencillo, económico y lo menos doloroso posible, por lo que no tienes excusas para no utilizarlo.

Hay tres proveedores de certificado respaldados en Trellis:

HTTPS puede ser habilitado por sitio. Sin embargo, por defecto, habilitando SSL en un sitio hará ese sitio únicamente HTTPS. Esto significa que todos los requests HTTP serán redirigidos a HTTPS con los HSTS headers correspondientes. Al menos que tengas una buena razón para cambiar esta configuración predeterminada, no deberías editarla. Mira la sección HSTS para mayor detalle.

El soporte de CloudFlare Origin CA puede ser agregado con trellis-cloudflare-origin-ca.

Configuración

Cualquier proveedor SSL comienza con la misma configuración básica. Agrega lo siguiente a un sitio WP:

# group_vars/production/wordpress_sites.yml (ejemplo)

example.com:
  # resto de la configuración de sitio
  ssl:
    enabled: true
    provider: <name>

Let's Encrypt

Let's Encrypt (LE) es una nueva Autoridad de Certificado que es gratuita, automatizada, y abierta.

Al menos que ya cuentes con certificado SSL, Let's Encrypt ha de ser tu elección de proveedor. Let's Encrypt es apropiado para tus servidores de producción y staging, pero no para desarrollo (vea registros DNS).

Trellis tiene una integración automatizada completa. El único ajuste requerido es el provider:

# group_vars/production/wordpress_sites.yml (ejemplo)

example.com:
  # resto de la config del sitio
  ssl:
    enabled: true
    provider: letsencrypt

Hay una diferencia principal entre LE y otras autoridades de certificados: sus certificados vencen cada 90 days. Trellis automatiza corriendo un cron-job para que nunca debas renovar manualmento o preocuparte por el vencimiento como sucede con los certificados pagos.

Registros DNS

Let's Encrypt verifica y crea certificados a través de un servidor web de acceso público para cada dominio que quieres en ese certificado.

Esto significa que necesitas un registro DNS válido y funcionando para cada host/dominio de cada sitio configurado en tu sitio WP.

# group_vars/production/wordpress_sites.yml (ejemplo)

midominio.com:
  site_hosts:
    - canonical: midominio.com
      redirects:
        - www.midominio.com
        - midominiotoredirect.com
        - www.midominiotoredirect.com
  ssl:
    enabled: true
    provider: letsencrypt

En el ejemplo de arriba, Trellis intentará automáticamente crear un certificado con los siguientes hosts: midominio.com, www.midominio.com, midominiotoredirect.com y www.midominiotoredirect.com.

Todo lo que necesitas hacer es asegurarte que los registros DNS existen y apunten a la IP del servidor web. Trellis se ocupa del resto.

Si quieres un subdominio "www" que redirija al canonical domain, DEBEN ser incluidos en los redirects.

Desafíos

El proceso de encriptación de Let's Encrypt sigue estos pasos, básicamente:

  1. Genera una private account key
  2. Genera una private key para cada sitio (puede tener múltiples dominios)
  3. Genera CSR (Certificate Signing Request) para cada sitio (único/multiples dominios)
  4. Solicita un certificado de LE enviándoles la account key y el CSR
  5. El cliente LE crea un "challenge" file en la raíz web del tu sitio
  6. El servidor LE verifica que puede acceder a ese challenge file
  7. El servidor LE envía un certificado si el challenge es correcto.

Estos pasos de arriba son manejados automáticamente por Trellis.

Servidore múltiples

La integración de Trellis con LE está diseñada por default para un único servidor. Si tienes muchos servidores web detrás de un load balancer, not querrás tener este rol/proceso ejecutándose en todos ellos debido a que generará diferentes private y account keys en cada uno de ellos.

Este proceso escapa a la documentación por el momento. Sin embargo, hay dos variables que ayudan para este proceso:

  • letsencrypt_account_key_source_content
  • letsencrypt_account_key_source_file

Puedes utilizar cualquiera de ellas para definir manualmente el contenido de una account key o archivo. Si alguna de estas está definida, será utilizada y ninguna de ellas será generada automáticamente.

Dependerá de ti asegurarse que ha registrado manualmente la account key. Vea https://gethttpsforfree.com/ para tener un ejemplo simple a mano.

Staging

Let's Encrypt tiene límites para sus certificados reales o en producción. Mientras Trellis prevendrá que estos límites se excedan, si quieres probar nuestra integración LE, puedes utilizar su servidor staging para obtener un certificado "fake".

Notese que los browsers mostrarán un error o advertencia que no reconocen la Autoridad del Certificado como válida por lo que esto solo debe ser utilizado para propósitos de prueba.

Simplemente configure la siguiente variable:

# dentro de un archivo group_vars
letsencrypt_ca: 'https://acme-staging.api.letsencrypt.org'

Problemas frecuentes en Let's Encrypt

Las versiones de Trellis anteriores a Ene 2017 no detectan algunos cambios que deberían provocar la regeneración del certificado Let's Encrypt. El ejemplo más común eran usuarios agregando dominios a site_hosts (en wordpress_sites) y reportando que los browsers arrojaban advertencias de privacidad en nuevos dominios. Problemas similares ocurrieron para usuarios haciendo el cambio de certificados manuales a certificados Let's Encrypt.

Si observas advertencias de privacidad similares luego de ajustar la configuración SSL de alguna manera, estos pasos pueden ayudar:

  1. Actualiza trellis para que incluya roots/trellis#630
  2. Configure ssl enabled: false para los sitios que están siendo afectados en group_vars/<environment>/wordpress_sites.yml
  3. Ejecute ansible-playbook server.yml -e env=<environment> --tags wordpress
  4. Cambie ssl enabled: true para los sitios que desactivó en group_vars/<environment>/wordpress_sites.yml
  5. Ejecute ansible-playbook server.yml -e env=<environment> --tags letsencrypt

Manual

Esto significa que usted está proveyendo el certificado SSL y la private key. Este fue el método original incluido en Trellis.

# group_vars/production/wordpress_sites.yml (ejemplo)

example.com:
  # resto de la configuración del sitio
  ssl:
    enabled: true
    provider: manual
    cert: ~/ssl/example.com.crt
    key: ~/ssl/example.com.key

cert y key son rutas locales relativas a estos archivos. Serán copiadas en los servidores remotors. Esto se realiza para que tu private key no tenga que ser alojada en el repositorio Git por razones de seguridad.

Self-signed (autofirmado)

El proveedor self-signed debe ser únicamente utilizado para desarrollo o para servidores internos. Trellis generará un certificado "fake" (o "snake-oil") que no es reconocido por browsers.

Notese que los browsers mostrarán un error o advertencia que no reconocen la Autoridad del Certificado como válida.

# group_vars/development/wordpress_sites.yml (ejemplo)

example.com:
  # rest of site config
  ssl:
    enabled: true
    provider: self-signed

HSTS

Trellis define encabezados HSTS para tener una mejor seguridad. HSTS asegurará que todo el tráfico de tu sitio sea dirigido a través de HTTPS en forma automática.

Hay algunos valores predeterminados que pueden ser editados si es necesario:

  • hsts_max_age - por cuánto tiempo perdura el encabezado (default: 31536000 (1 año))
  • hsts_include_subdomains - además hace que todos los subdominios sean dirigidos a través de https (default: true)
  • hsts_preload - indica el consetimiento del dueño del sitio a tener el dominio precargado (default: false)

Estas variables son configuradas en un objeto ssl del sitio:

# group_vars/production/wordpress_sites.yml (ejemplo)

example.com:
  # configuración del resto del sitio
  ssl:
    enabled: true
    provider: letsencrypt
    hsts_max_age: 31536000
    hsts_include_subdomains: true
    hsts_preload: true

Listas de precarga

Que es la precarga HSTS?

La precarga HSTS es un mecanismo en donde una lista de hosts que desean reforzar el uso de SSL/TLS en su sitio en el armado en el browser. Esta lista está compilada por Google y es utilizada por Chrome, Firefox, Opera, Safari, IE11 y Edge. Estos sitios no dependen de la respuesta del encabezado HSTS para reforzar la norma, ya que el browser está avisado que el host necesita el uso de SSL/TLS antes que cualquier comunicación o conexión sea llevada a cabo. Esto elimina la posibilidad que un atacante pueda interceptar y manipule con redireccionamientos que se realizan mientras se encuentran en HTTP. Esto no significa que el host debe dejar de emitir la respuesta de encabezado HSTS, ya que puede haber browsers que no utilicen esta lista de precarga.

  • https://scotthelme.co.uk/hsts-preloading/

La utilización de la precarga es un proceso de dos pasos:

  1. Habilite la opción preload mostrada arriba en el setting hsts_preload: true
  2. Envíe su sitio/dominio a la lista oficial de precarga en browsers: https://hstspreload.org/

Más información:

max-age

El valor por default de max-age es 31536000 segundos (1 año).

Puedes probar HSTS con mucho menos max-ages y luego elevar el valor hasta que estés seguro que todo funciona correctamente.

Este proceso de elevación de deployment se detalla aquí: https://hstspreload.org/#deployment-recommendations

Deshabilitar HSTS

La única forma de deshabilitar HSTS es configurar el encabezado max-age en 0:

# group_vars/production/wordpress_sites.yml (example)

example.com:
  # rest of site config
  ssl:
    enabled: true
    provider: letsencrypt
    hsts_max_age: 0

hsts_include_subdomains

HSTS idealmente debe ser aplicado a todos los subdominios, es por eso que hsts_include_subdomains está configurado como true. Esto significa que si tienes habilitado HSTS en example.com, entonces todos sus subdominios (*.example.com) serán forzados a HTTPS.

Si tienes un sitio WordPress en example.com y también sirves otra aplicación desde un subdominio como internalapp.example.com, puede que necesites eliminar la opción de encabezado "include subdomains" si no puede ser utilizada via HTTPS.

# group_vars/production/wordpress_sites.yml (ejemplo)

example.com:
  # rest of site config
  ssl:
    enabled: true
    provider: letsencrypt
    hsts_max_age: 31536000
    hsts_include_subdomains: false
    hsts_preload: true

Tenga en cuenta que es muy importante dar soporte SSL/HTTPS en todos los subdominios. Solo deshabilita esta opción como el último recurso.

Funcionamiento

Nuestra implementación HTTPS utiliza todas las optimizaciones posibles para asegurar que todos los sitios se mantengan veloces a pesar de los agregados de SSL. Esto incluye las siguientes características:

  • HTTP/2 support (fallback to HTTP/1.1 for older browsers)
  • SSL session cache
  • OCSP stapling
  • 1400 byte TLS records
  • Keepalives más largos

Vea TLS ya es veloz? para mayor información sobre TLS/SSL.

Compatibilidad con browsers

Desde nuestra implementación diseñada para ser moderno y alcanzar un puntaje A+ en los Qualys SSL Labs Test, esto puede significar que algunos browsers antiguos como IE6 no podrán acceder a tu sitio debido a las combinaciones de cifrado utilizados.

← Acceso a la Base de Datos →