One place for hosting & domains

      Usar una CDN para acelerar la entrega de contenido


      Introducción

      Las aplicaciones y los sitios web modernos deben a menudo proporcionar un volumen considerable de contenido estático a los usuarios finales. Este contenido incluye imágenes, hojas de estilos, JavaScript y video. A medida que aumentan la cantidad y el tamaño de estos recursos estáticos, lo mismo sucede con el uso del ancho de banda y los tiempos de carga de la página. Esto genera perjuicios en la experiencia de navegación de los usuarios y reduce la capacidad disponible en sus servidores.

      Para reducir drásticamente los tiempos de carga de la página, mejorar el rendimiento y recortar sus costos de ancho de banda e infraestructura, puede implementar una CDN, o red de entrega de contenido, para almacenar en caché estos recursos en un conjunto de servidores distribuidos geográficamente.

      En este tutorial, ofrecemos una descripción de alto nivel de las CDN, su funcionamiento y los beneficios que ofrecen para sus aplicaciones web.

      ¿Qué es una CDN?

      Una red de entrega de contenido es un grupo de servidores distribuidos geográficamente y optimizados para proporcionar contenido estático a los usuarios finales. Este contenido estático corresponder a casi cualquier tipo de datos, pero las CDN se utilizan sobre todo para entregar páginas web y sus archivos relacionados, y transmitir vídeo y audio además de grandes paquetes de software.

      Diagrama de entrega de contenido sin una CDN

      Una CDN consta de varios puntos de presencia (PoP) en varias ubicaciones, y cada uno de ellos consta de numerosos servidores perimetrales que almacenan en caché recursos de su origen o servidor host. Cuando un usuario visita su sitio web y solicita recursos estáticos, como imágenes o archivos de JavaScript, la CDN redirecciona sus solicitudes al servidor perimetral más cercano, desde el cual se proporciona el contenido. Si los recursos no están almacenados en caché en el servidor perimetral, o si los recursos almacenados en caché caducaron, la CDN buscará y almacenará en caché la versión más reciente desde otro servidor perimetral de CDN cercano o desde sus servidores de origen. Si la CDN perimetral no tiene una entrada almacenada en caché para sus recursos (lo cual sucede en la mayoría de los casos si su sitio web recibe una cantidad moderada de tráfico), mostrará la copia en caché al usuario final.

      Diagrama de la red de entrega de contenido (CDN)

      Esto permite que los usuarios dispersos geográficamente reduzcan al mínimo el número de saltos necesarios para recibir contenido estático y buscar el contenido directamente en la caché de un servidor perimetral cercano. Como resultado, se reducen considerablemente las latencias y la pérdida de paquetes, se acelera la carga de páginas y disminuye de forma drástica la carga para su infraestructura de origen.

      Por un costo adicional, los proveedores de CDN a menudo ofrecen funciones adicionales, como la mitigación de DDoS y limitación de velocidad, los análisis de usuarios y las optimizaciones para casos de uso de transmisión o plataformas móviles.

      ¿Cómo funciona una CDN?

      Cuando un usuario visita su sitio web, primero recibe una respuesta de un servidor DNS que contiene la dirección IP de su servidor web host. Su navegador luego solicita el contenido de la página web, que a menudo consiste en una variedad de archivos estáticos, como páginas HTML, hojas de estilos CSS, código JavaScript e imágenes.

      Una vez que implementa una CDN y descarga estos recursos estáticos en servidores CDN, ya sea “forzándolos” manualmente o haciendo que la CDN “extraiga” los recursos automáticamente (ambos mecanismos se explican en la sección siguiente), indicará a su servidor web que reescriba los enlaces al contenido estático de modo que apunten a los archivos alojados por la CDN. Si está usa un CMS como WordPress, esta reescritura puede implementarse usando un complemento externo, como CDN Enabler.

      Muchas CDN ofrecen soporte para dominios personalizados, lo que le permite crear un registro CNAME en su dominio apuntando a un extremo de la CDN. Una vez que la CDN recibe una solicitud de usuario en este extremo (ubicado en el servidor perimetral, mucho más cerca del usuario que sus servidores de backend), dirige la solicitud al punto de presencia (PoP) ubicado más cerca del usuario. Este PoP a menudo consta de uno o más servidores perimetrales de CDN, localizados de forma conjunta en un punto de intercambio de Internet (IxP), que es básicamente un centro de datos que los proveedores de servicios de Internet (ISP) utilizan para interconectar sus redes. El equilibrador de carga interna de la CDN dirige la solicitud a un servidor perimetral ubicado en este PoP, que luego proporciona el contenido al usuario.

      Los mecanismos de almacenamiento en caché varían según el proveedor de la CDN, pero generalmente funcionan de la siguiente manera:

      1. Cuando la CDN recibe una primera solicitud de un recurso estático, como una imagen PNG, no dispone del archivo en caché y debe obtener una copia del recurso desde un servidor edge CDN cercano o desde el servidor de origen. Esto se conoce como “miss.” de la memoria caché y normalmente se puede detectar inspeccionando el encabezado de la respuesta HTTP, que contiene X-Cache: MISS. Esta solicitud inicial será más lenta que las solicitudes futura,debido a que, tras completarla, el recurso quedará almacenado en la memoria caché del servidor perimetral.
      2. Las solicitudes futuras de este recurso (“aciertos” de caché) dirigidas a esta ubicación perimetral ahora se proporcionarán desde la memoria caché hasta su vencimiento (normalmente configurado en los encabezados HTTP). Estas respuestas serán considerablemente más rápidas que la solicitud inicial, lo que reducirá de forma notable las latencias para los usuarios y descargará tráfico web a la red CDN. Puede verificar que la respuesta se proporcionó desde la caché de la CDN inspeccionando el encabezado de la respuesta HTTP, que ahora debería contener X-Cache: HIT.

      Para obtener más información sobre cómo funciona y cómo se implementó una CDN específica, consulte la documentación su proveedor de CDN.

      En la siguiente sección, se presentarán los dos tipos populares de CDN: push y pull.

      Zonas de incorporación vs. zonas de obtención

      La mayoría de los proveedores de CDN ofrecen dos alternativas para almacenar sus datos en caché: las zonas de obtención y las de incorporación.

      En el caso de las zonas de obtención se debe introducir la dirección de su servidor de origen y permitir que la CDN busque y almacene en caché de forma automática todos los recursos estáticos disponibles en su sitio. Estas zonas normalmente se utilizan para proporcionar recursos web que se actualizan con frecuencia y tienen tamaños entre reducidos y medianos, como los HTML, CSS y los de Java Script. Una vez que se proporciona a la CDN la dirección de su servidor de origen, el siguiente paso es normalmente reescribir los enlaces a los recursos estáticos, de modo que apunten a la URL proporcionada por la CDN. A partir de ese momento, la CDN gestionará las solicitudes de recursos entrantes de sus usuarios y proporcionará contenido desde sus cachés distribuidas geográficamente y desde su origen, según corresponda.

      Para usar una zona de incorporación, se suben los datos a una ubicación de almacenamiento o un depósito designados que luego la CDN introduce en memorias caché de su flota de servidores perimetrales distribuidos. Las zonas push se usan normalmente para archivos más grandes que apenas cambian, como los que se encuentran en ficheros, paquetes de software, PDF, videos y audio.

      Beneficios del uso de una CDN

      Casi cualquier sitio puede aprovechar los beneficios obtenidos al implementar una CDN, pero generalmente el motivo principal por el cual se implementa tiene que ver con la descarga ancho de banda de sus servidores de origen a los servidores de la CDN y la reducción de la latencia para los usuarios distribuidos geográficamente.

      A continuación, repasaremos estas y otras ventajas principales del uso de una CDN.

      Generar descarga

      Si está cerca de utilizar la capacidad de ancho de banda de sus servidores, la descarga de recursos estáticos como imágenes, videos, CSS y archivos de JavaScript reducirá drásticamente el uso de ancho de banda por parte de sus servidores. Las redes de entrega de contenido se diseñan y optimizan para proporcionar contenido estático, y las solicitudes de clientes para este contenido se dirigirán a servidores perimetrales de CDN y se proporcionarán en ellos. Esto tiene el beneficio adicional de reducir la carga en sus servidores de origen, ya que proporcionan estos datos a una frecuencia mucho más baja.

      Reducir la latencia para mejorar la experiencia del usuario

      Si su base de usuarios está dispersa geográficamente y una parte de su tráfico que no es poco representativa proviene de una zona geográfica distante, una CDN puede disminuir la latencia almacenando en caché los recursos estáticos en servidores perimetrales más cercanos a sus usuarios. Al reducir la distancia entre sus usuarios y el contenido estático, puede entregar contenido de forma más rápida a sus usuarios y mejorar su experiencia aumentando las velocidades de carga de la página.

      Estos beneficios se acentúan en el caso de los sitios web que proporcionan principalmente contenido de video que exige mucho ancho de banda, en los cuales las altas latencias y los tiempos de carga prolongados tienen un impacto más directo sobre la experiencia del usuario y el compromiso con el contenido.

      Gestionar picos de tráfico y evitar tiempo de inactividad

      Las CDN le permiten gestionar grandes picos y aumentos de tráfico al equilibrar la carga de las solicitudes en una red grande y distribuida de servidores perimetrales. Al descargar y almacenar contenido estático en una red de entrega, puede acomodar un número mayor de usuarios simultáneos con su infraestructura existente.

      Para los sitios web que usen un servidor de origen único, estos grandes picos de tráfico a menudo pueden sobrecargar el sistema, y producir desconexiones y tiempo de inactividad no planificados. El cambio del tráfico a una infraestructura de CDN altamente disponible y redundante, diseñada para gestionar niveles variables de tráfico web, puede aumentar la disponibilidad de sus recursos y contenido.

      Reducir costos

      Debido a que el aprovisionamiento de contenido estático normalmente ocupa la mayor parte del uso de su ancho de banda, la descarga de estos recursos a una red de entrega de contenido puede reducir notablemente sus costos mensuales de infraestructura. Además de reducir los costos de ancho de banda, una CDN puede disminuir los cargos de servidores mediante la reducción de la carga en los servidores de origen, lo cual permite la expansión de su infraestructura existente. Por último, algunos proveedores de CDN ofrecen facturación mensual fija, lo que le permite transformar su consumo de ancho de banda mensual variable en un gasto recurrente estable y predecible.

      Aumentar la seguridad

      Las CDN también se usan comúnmente para mitigar ataques de DDoS. Muchos proveedores de CDN incluyen funciones para controlar y filtrar solicitudes a servidores perimetrales. Estos servicios analizan el tráfico web para detectar patrones sospechosos y bloquean el tráfico de ataques malintencionados mientras permiten el tráfico de los usuarios de confianza. Los proveedores de CDN suelen ofrecer varios servicios de mitigación de DDoS, desde la protección contra ataques comunes a nivel de la infraestructura (capas 3 y 4 de la OSI) hasta servicios de mitigación y limitación de índices más avanzados.

      Además, la mayoría de las CDN le permiten configurar SSL completo, con lo cual puede cifrar el tráfico entre la CDN y el usuario final, así como el tráfico entre la CDN y sus servidores de origen, usando certificados proporcionados por la CDN o SSL personalizados.

      Elegir la mejor solución

      Si su obstáculo es la carga sobre la CPU en el servidor de origen, y no el ancho de banda, es posible que una CDN no sea la solución más apropiada. En este caso, el almacenamiento en cachés locales mediante cachés populares como NGINX o Varnish puede reducir considerablemente la carga proporcionando recursos desde la memoria del sistema.

      Antes de implementar una CDN, los pasos de optimización adicionales (como los de minificar y comprimir archivos de JavaScript y CSS, y permitir la compresión de la solicitud HTTP del servidor web) pueden tener un impacto considerable en los tiempos de carga de la página y el uso del ancho de banda.

      Una herramienta útil para medir la velocidad de carga de su página y mejorarla es PageSpeed Insights, de Google. Otra herramienta útil que proporciona un desglose de los tiempos de respuesta y las optimizaciones sugeridas es Pingdom.

      Conclusión

      Una red de entrega de contenido puede ser una solución rápida y eficaz para mejorar la escalabilidad y disponibilidad de sus sitios web. Al almacenar en caché los recursos estáticos en una red distribuida de servidores optimizados, puede reducir enormemente los tiempos de carga de la página y las latencias para los usuarios finales. Además, las CDN le permiten reducir considerablemente el uso de ancho de banda absorbiendo las solicitudes de los usuarios y respondiendo desde la memoria caché perimetral, lo que disminuye sus costos de ancho de banda e infraestructura.

      Gracias a complementos y compatibilidad con plataformas externas para los principales marcos, como WordPress, Drupal, Django y Ruby on Rails, además de funciones adicionales como la mitigación de DDoS, SSL completo, la monitorización de usuarios y la compresión de recursos, las CDN pueden ser una herramienta muy útil para proteger y optimizar sitios web con un alto nivel de tráfico.



      Source link

      Cómo crear un certificado SSL autofirmado para Apache en Ubuntu 18.04


      Justin Ellingwood escribió una versión anterior de este tutorial.

      Introducción

      La TLS, o seguridad en la capa de transporte, y la SSL, plataforma antecesora cuya sigla significa “capa de sockets seguros”, son protocolos web que se utilizan para envolver el tráfico normal con una cobertura protegida cifrada.

      Mediante esta tecnología, los servidores pueden enviar tráfico de forma segura entre servidores y clientes sin la posibilidad de que los mensajes sean interceptados por terceros. El sistema de certificado también ayuda a los usuarios a verificar la identidad de los sitios con los que establecen conexión.

      En esta guía, le mostraremos la manera de configurar un certificado SSL autofirmado para su uso con un servidor web de Apache en Ubuntu 18.04.

      Nota: Un certificado autofirmado cifrará la comunicación entre su servidor y cualquier cliente. Sin embargo, dado que no está firmado por ninguna de las autoridades certificadoras de confianza incluidas con los navegadores web, los usuarios no pueden usar el certificado para validar la identidad de su servidor de forma automática.

      Es posible que un certificado autofirmado sea apropiado si no dispone de un nombre de dominio asociado con su servidor y para casos en los que una interfaz web cifrada no esté dirigida al usuario. Si dispone de un nombre de dominio, en muchos casos es mejor usar un certificado firmado por una autoridad certificadora (CA). Puede averiguar la manera de configurar un certificado de confianza gratuito a través del proyecto Let´s Encrypt aquí.

      Requisitos previos

      Antes de comenzar, deberá contar con un usuario no root configurado con privilegios sudo. Puede aprender a configurar una cuenta de usuario de este tipo siguiendo nuestra Configuración inicial de servidores con Ubuntu 18.04.

      También deberá tener instalado el servidor web de Apache. Si desea instalar una pila LAMP completa (Linux, Apache, MySQL y PHP) en su servidor, puede seguir nuestra guía de configuración de LAMP en Ubuntu 18.04. Si solo quiere el servidor web de Apache, omita los pasos correspondientes a PHP y MySQL.

      Una vez que cumpla con los requisitos previos, siga los pasos que se muestran a continuación.

      Paso 1: Crear el certificado SSL

      La TLS y la SSL funcionan utilizando una combinación de un certificado público y una clave privada. La clave SSL se mantiene secreta en el servidor. Se utiliza para cifrar contenido que se envía a los clientes. El certificado SSL se comparte de forma pública con cualquiera que solicite el contenido. Puede utilizarse para descifrar el contenido firmado por la clave SSL asociada.

      Podemos crear un par de clave y certificado autofirmados con OpenSSL en un único comando:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

      Se le harán varias preguntas. Antes de abordar eso, observemos lo que sucede en el comando que emitimos:

      • openssl: es la herramienta de línea de comandos básica para crear y administrar certificados, claves, y otros archivos de OpenSSL.
      • req: este subcomando especifica que deseamos usar la administración de la solicitud de firma de certificados (CSR) X.509. El “X.509” es un estándar de infraestructura de claves públicas al que se adecuan SSL y TLS para la administración de claves y certificados a través de él. Queremos crear un nuevo certificado X.509, por lo que usaremos este subcomando.
      • -x509: modifica aún más el subcomando anterior al indicar a la utilidad que deseamos crear un certificado autofirmado en lugar de generar una solicitud de firma de certificados, como normalmente sucede.
      • -nodes: indica a OpenSSL que omita la opción para proteger nuestro certificado con una frase de contraseña. Necesitamos que Apache pueda leer el archivo, sin intervención del usuario, cuando se inicie el servidor. Una frase de contraseña evitaría que esto suceda porque tendríamos que ingresarla tras cada reinicio.
      • -days 365: esta opción establece el tiempo durante el cual el certificado se considerará válido. En este caso, lo configuramos por un año.
      • -newkey rsa:2048: especifica que deseamos generar un nuevo certificado y una nueva clave al mismo tiempo. No creamos la clave que se requiere para firmar el certificado en un paso anterior, por lo que debemos crearla junto con el certificado. La parte rsa:2048 le indica que cree una clave RSA de 2048 bits de extensión.
      • -keyout: esta línea indica a OpenSSL dónde colocar el archivo de clave privada generado que estamos creando.
      • -out: indica a OpenSSL dónde colocar el certificado que creamos.

      Como se mencionó anteriormente, estas opciones crearán un archivo de clave y un certificado. Se harán algunas preguntas sobre nuestro servidor con el fin de insertar la información de forma correcta en el certificado.

      Complete las solicitudes de forma adecuada. La línea más importante es aquella en la que se solicita Common Name (e.g. server FQDN or YOUR name). Debe ingresar el nombre de dominio asociado con su servidor o, lo más probable, la dirección IP pública de su servidor.

      La totalidad de las solicitudes tendrán un aspecto similar a este:

      Output

      Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:server_IP_address Email Address []:admin@your_domain.com

      Los dos archivos que creó se ubicarán en los subdirectorios correspondientes en /etc/ssl.

      Paso 2: Configurar Apache para usar SSL

      Hemos creado nuestros archivos de clave y certificado en el directorio /etc/ssl. Ahora solo debemos modificar nuestra configuración de Apache para aprovecharlos.

      Aplicaremos algunos ajustes a nuestra configuración:

      1. Crearemos un fragmento de configuración para especificar configuraciones SSL seguras predeterminadas.
      2. Modificaremos el archivo de host virtual de Apache SSL incluido para apuntar a los certificados SSL que generamos.
      3. (Recomendado) Modificaremos el archivo de host virtual no cifrado para redireccionar las solicitudes de forma automática al host virtual cifrado.

      Al terminar, deberíamos contar con una configuración SSL segura.

      Crear un fragmento de configuración de Apache con ajustes de cifrado seguro

      Primero, crearemos un fragmento de configuración de Apache para definir algunos ajustes de SSL. Con esto, se configurará Apache con un conjunto de cifrado SSL seguro y se habilitarán algunas características avanzadas que ayudarán a mantener protegido nuestro servidor. Los parámetros que configuraremos pueden utilizarse a través de cualquier hosting virtual que habilite SSL.

      Cree un nuevo fragmento en el directorio /etc/apache2/conf-available. Daremos el nombre ssl-params.conf al archivo para que quede claro su propósito:

      • sudo nano /etc/apache2/conf-available/ssl-params.conf

      Para configurar Apache SSL de forma segura, usaremos las recomendaciones que Remy van Elst da en el sitio de Cipherli.st. Este sitio está diseñado para proporcionar configuraciones de cifrado fáciles de utilizar para software popular.

      Las configuraciones propuestas en el sitio del vínculo anterior ofrecen una seguridad confiable. A veces, esto se hace a costa de una mayor compatibilidad con el cliente. Si necesita ofrecer compatibilidad con clientes anteriores, existe una lista alternativa a la que se puede acceder haciendo clic en el enlace de la página con la etiqueta “Sí, quiero un conjunto de cifrado que funcione con el software anterior o heredado”. Esa lista puede sustituirse por los elementos copiados a continuación.

      La elección de la configuración que utilizará dependerá en gran medida de aquello para lo que deba ofrecer compatibilidad. Ambas opciones proporcionarán una gran seguridad.

      Para nuestros propósitos, podemos copiar las configuraciones proporcionadas en su totalidad. Sólo haremos un pequeño cambio. Deshabilitaremos el encabezado Strict-Transport-Security (HSTS).

      La precarga del HSTS proporciona una mayor seguridad, pero puede tener consecuencias importantes si se habilita accidentalmente o de forma incorrecta. En esta guía, no habilitaremos las configuraciones, pero puede aplicar una modificación si está seguro de comprender las implicaciones.

      Antes de tomar una decisión, tómese un momento para informarse sobre seguridad estricta de transporte de HTTP, o HSTS, y en particular sobre la funcionalidad “preload”.

      Pegue la configuración en el archivo ssl-params.conf que abrimos:

      /etc/apache2/conf-available/ssl-params.conf

      SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
      SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
      SSLHonorCipherOrder On
      # Disable preloading HSTS for now.  You can use the commented out header line that includes
      # the "preload" directive if you understand the implications.
      # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
      Header always set X-Frame-Options DENY
      Header always set X-Content-Type-Options nosniff
      # Requires Apache >= 2.4
      SSLCompression off
      SSLUseStapling on
      SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
      # Requires Apache >= 2.4.11
      SSLSessionTickets Off
      

      Guarde y cierre el archivo cuando haya terminado.

      Modificar el archivo de host virtual de Apache SSL predeterminado

      A continuación, modificaremos /etc/apache2/sites-available/default-ssl.conf, el archivo de host virtual de SSL predeterminado. Si usa un archivo de bloque de servidor diferente, sustituya su nombre en los comandos que se muestran a continuación.

      Antes de continuar, realizaremos una copia de seguridad del archivo original de host virtual de SSL:

      • sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

      Ahora, abra el archivo de host virtual de SSL para realizar ajustes:

      • sudo nano /etc/apache2/sites-available/default-ssl.conf

      En su interior, con la mayoría de los comentarios eliminados, el archivo de host virtual debería tener un aspecto similar al siguiente por defecto:

      /etc/apache2/sites-available/default-ssl.conf

      <IfModule mod_ssl.c>
              <VirtualHost _default_:443>
                      ServerAdmin webmaster@localhost
      
                      DocumentRoot /var/www/html
      
                      ErrorLog ${APACHE_LOG_DIR}/error.log
                      CustomLog ${APACHE_LOG_DIR}/access.log combined
      
                      SSLEngine on
      
                      SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                      SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
      
                      <FilesMatch ".(cgi|shtml|phtml|php)$">
                                      SSLOptions +StdEnvVars
                      </FilesMatch>
                      <Directory /usr/lib/cgi-bin>
                                      SSLOptions +StdEnvVars
                      </Directory>
      
              </VirtualHost>
      </IfModule>
      

      Haremos algunos ajustes menores en el archivo. Configuraremos las cosas normales que querríamos ajustar en un archivo de host virtual (dirección de correo electrónico de ServerAdmin, ServerName, etc.), y ajustaremos las directivas SSL para que apunten a nuestros archivos de certificados y claves.

      Tras realizar estos cambios, su bloque de servidor debe tener un aspecto similar a este:

      /etc/apache2/sites-available/default-ssl.conf

      <IfModule mod_ssl.c>
              <VirtualHost _default_:443>
                      ServerAdmin your_email@example.com
                      ServerName server_domain_or_IP
      
                      DocumentRoot /var/www/html
      
                      ErrorLog ${APACHE_LOG_DIR}/error.log
                      CustomLog ${APACHE_LOG_DIR}/access.log combined
      
                      SSLEngine on
      
                      SSLCertificateFile      /etc/ssl/certs/apache-selfsigned.crt
                      SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
      
                      <FilesMatch ".(cgi|shtml|phtml|php)$">
                                      SSLOptions +StdEnvVars
                      </FilesMatch>
                      <Directory /usr/lib/cgi-bin>
                                      SSLOptions +StdEnvVars
                      </Directory>
      
              </VirtualHost>
      </IfModule>
      

      Guarde y cierre el archivo cuando haya terminado.

      (Recomendado) Modificar el archivo de host HTTP para el redireccionamiento a HTTPS

      En su estado actual, el servidor proporcionará tanto tráfico HTTP no cifrado como tráfico HTTPS cifrado. Para una mayor seguridad, en la mayoría de los casos se recomienda redireccionar HTTP a HTTPS de forma automática. Si no desea ni necesita esta funcionalidad, puede omitir esta sección sin riesgo.

      Para ajustar el archivo de host virtual no cifrado de modo que se redireccione todo el tráfico y cuente con cifrado SSL, podemos abrir el archivo /etc/apache2/sites-available/000-default.conf:

      • sudo nano /etc/apache2/sites-available/000-default.conf

      Dentro de los bloques de configuración de VirtualHost, debemos añadir una directiva Redirect, que dirija todo el tráfico a la versión SSL del sitio:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:80>
              . . .
      
              Redirect "/" "https://your_domain_or_IP/"
      
              . . .
      </VirtualHost>
      

      Guarde y cierre el archivo cuando haya terminado.

      Paso 3: Ajustar el firewall

      Si tiene habilitado el firewall ufw, como se recomienda en las guías de los requisitos previos, es posible que deba ajustar la configuración para permitir el tráfico de SSL. Afortunadamente, Apache registra algunos perfiles con ufw después de la instalación.

      Podemos ver los perfiles disponibles escribiendo lo siguiente:

      Debería ver una lista como esta:

      Output

      Available applications: Apache Apache Full Apache Secure OpenSSH

      Puede ver la configuración actual escribiendo lo siguiente:

      Si antes sólo permitía tráfico HTTP regular, su resultado puede tener este aspecto:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Para permitir adicionalmente la entrada de tráfico HTTPS, podemos permitir el perfil “Apache Full” y luego eliminar la asignación de perfil “Apache” redundante:

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Con esto, su estado debería de tener este aspecto:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Paso 4: Habilitar los cambios en Apache

      Ahora que realizamos los cambios y ajustamos el firewall, podemos habilitar los módulos y encabezados SSL de Apache, y también nuestro host virtual listo para SSL, y reiniciar Apache.

      Podemos habilitar mod_ssl, el módulo SSL de Apache y mod_headers, que necesitan algunas de las configuraciones de nuestro fragmento SSL, con el comando a2enmod:

      • sudo a2enmod ssl
      • sudo a2enmod headers

      A continuación, podemos habilitar nuestro host virtual SSL con el comando a2ensite:

      • sudo a2ensite default-ssl

      También debemos habilitar nuestro archivo ssl-params.conf, para leer los valores que configuramos:

      En este punto, nuestro sitio y los módulos necesarios quedarán habilitados. Deberíamos comprobar que no haya errores de sintaxis en nuestros archivos. Podemos hacerlo escribiendo lo siguiente:

      • sudo apache2ctl configtest

      Si la operación se completa de forma correcta, obtendrá un resultado similar a este:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      La primera línea es solo un mensaje que le indica que la directiva ServerName no está configurada a nivel global. Si quiere deshacerse de ese mensaje, puede establecer ServerName en el nombre de dominio o la dirección IP de su servidor en /etc/apache2/apache2.conf. Esto es opcional, ya que el mensaje no causará problemas.

      Si el resultado contiene Syntax OK, en su archivo de configuración no habrá errores de sintaxis. Podemos reiniciar Apache de forma segura para implementar nuestros cambios:

      • sudo systemctl restart apache2

      Paso 5: Probar el cifrado

      Ahora, estamos listos para probar nuestro servidor SSL.

      Abra su navegador web y escriba https:// seguido del nombre de dominio o el IP de su servidor en la barra de direcciones:

      https://server_domain_or_IP
      

      Debido a que el certificado que creamos no está firmado por una de las autoridades de certificados de confianza de su navegador, es probable que vea una advertencia de aspecto intimidante como la que aparece a continuación:

      Advertencia de certificado autofirmado de Apache

      Esto está previsto y es normal. Sólo nos interesa el aspecto de cifrado de nuestro certificado. No nos importa la validación de terceros de la autenticidad de nuestro host. Haga clic en “ADVANCED” y luego en el enlace proporcionado para acceder a su host de cualquier manera:

      Anulación autofirmada de Apache

      Debería acceder a su sitio. Si observa la barra de direcciones del navegador, verá un candado con una “x” encima. En este caso, esto solo significa que no es posible validar el certificado. Todavía se está cifrando su conexión.

      Si configuró Apache para redireccionar HTTP a HTTPS, también puede comprobar si el redireccionamiento funciona de manera correcta:

      http://server_domain_or_IP
      

      Si como resultado aparece el mismo icono, significa que el redireccionamiento funcionó de manera correcta.

      Paso 6: Cambiar a una redireccionamiento permanente

      Si su redireccionamiento funcionó de forma correcta y está seguro que quiere permitir solo tráfico cifrado, deberá modificar el host virtual de Apache no cifrado de nuevo para que el redireccionamiento sea permanente.

      Abra de nuevo el archivo de configuración de su bloque de servidor:

      • sudo nano /etc/apache2/sites-available/000-default.conf

      Encuentre la línea de Redirect que agregamos previamente. Añada permanent a esa línea, que cambia el redireccionamiento del tipo temporal 302 al tipo permanente 301:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:80>
              . . .
      
              Redirect permanent "/" "https://your_domain_or_IP/"
      
              . . .
      </VirtualHost>
      

      Guarde y cierre el archivo.

      Revise su configuración en busca de errores de sintaxis:

      • sudo apache2ctl configtest

      Cuando esté listo, reinicie Apache para que el redireccionamiento sea permanente:

      • sudo systemctl restart apache2

      Conclusión

      De esta manera, habrá configurado su servidor de Apache para aplicar un cifrado seguro a las conexiones de los clientes. Esto le permitirá proporcionar las solicitudes de forma segura y evitará que individuos externos lean su tráfico.



      Source link

      Como criar um certificado SSL autoassinado para o Apache no Ubuntu 18.04


      Uma versão anterior deste tutorial foi escrita por Justin Ellingwood.

      Introdução

      O TLS, ou segurança de camada de transporte e seu antecessor, o SSL, que significa camada de socket segura, são protocolos Web usados para envolver o tráfego normal em um pacote protegido e criptografado.

      Ao usar essa tecnologia, os servidores podem enviar tráfego com segurança entre servidores e clientes sem a possibilidade de mensagens serem interceptadas por agentes externos. O sistema de certificados também ajuda os usuários a verificar a identidade dos sites com os quais eles estão se conectando.

      Neste guia, mostraremos como configurar um certificado SSL autoassinado para uso com um servidor Web Apache no Ubuntu 18.04.

      Nota: um certificado autoassinado irá criptografar a comunicação entre seu servidor e qualquer cliente. No entanto, uma vez que ele não está assinado por nenhuma das autoridades de certificados confiáveis incluídas com navegadores Web, os usuários não podem usar o certificado para validar a identidade do seu servidor automaticamente.

      Um certificado autoassinado pode ser apropriado se você não tiver um nome de domínio associado ao seu servidor e para instâncias onde uma interface Web criptografada não seja voltada para o usuário. Se você tiver de fato um nome de domínio, em muitos casos é melhor usar um certificado assinado por CA. Você pode descobrir como configurar um certificado de confiança gratuito com o projeto Let’s Encrypt aqui

      Pré-requisitos

      Antes de começar, você deve ter um usuário não-raiz configurado com privilégios sudo. Você pode aprender como configurar esse tipo de usuário seguindo nossa Configuração inicial de servidor com o Ubuntu 18.04.

      Você também precisará ter o servidor Web Apache instalado. Se você quiser instalar uma pilha LAMP (Linux, Apache, MySQL, PHP) inteira no seu servidor, você pode seguir nosso guia sobre como configurar o LAMP no Ubuntu 18.04. Se você quiser apenas o servidor web Apache, pule os passos referentes ao PHP e MySQL.

      Quando tiver completado os pré-requisitos, continue abaixo.

      Passo 1 — Criando o certificado SSL

      O TLS/SSL funciona usando uma combinação de um certificado público e uma chave privada. A chave SSL é mantida em segredo no servidor. Ela é usada para criptografar o conteúdo enviado para clientes. O certificado SSL é compartilhado publicamente com qualquer um que solicitar o conteúdo. Ele pode ser usado para decifrar o conteúdo assinado pela chave SSL associada.

      Podemos criar um par chave autoassinada e certificado com o OpenSSL em um único comando:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

      Uma séria de questões será feita a você. Antes de passarmos por isso, vamos ver o que está acontecendo no comando que estamos emitindo:

      • openssl: esta é a ferramenta básica de linha de comando para criação e gerenciamento de certificados OpenSSL, chaves e outros arquivos.
      • req: este subcomando especifica que queremos usar o gerenciamento X.509 de solicitação de assinatura de certificado (CSR). O “X.509” é um padrão de infraestrutura de chave pública aderido pelo SSL e o TLS para seu gerenciamento de chaves e certificados. Queremos criar um novo cert X.509, então estamos usando este subcomando.
      • -x509: isso modifica ainda mais o subcomando anterior dizendo ao utilitário que queremos criar um certificado autoassinado em vez de gerar uma solicitação de assinatura de certificado, como normalmente aconteceria.
      • -nodes: isso diz ao OpenSSL para pular a opção de proteger nosso certificado com uma frase secreta. Precisamos que o Apache consiga ler o arquivo, sem a intervenção do usuário, quando o servidor for iniciado. Uma frase secreta impediria que isso acontecesse porque teríamos que digitá-la após cada reinício.
      • -days 365: esta opção define a duração do tempo em que o certificado será considerado válido. Aqui, nós configuramos ela para um ano.
      • -newkey rsa:2048: isso especifica que queremos gerar um novo certificado e uma nova chave ao mesmo tempo. Não criamos a chave necessária para assinar o certificado em um passo anterior, então precisamos criá-la junto com o certificado. A porção rsa:2048 diz a ele para criar uma chave RSA que seja de 2048 bits.
      • -keyout: esta linha diz ao OpenSSL onde colocar o arquivo gerado de chave privada que estamos criando.
      • -out: isso diz ao OpenSSL onde colocar o certificado que estamos criando.

      Como mostrado acima, essas opções criarão tanto um arquivo de chave como um certificado. Algumas perguntas sobre nosso servidor serão feitas para incorporar as informações corretamente no certificado.

      Preencha os prompts devidamente. A linha mais importante é aquela que solicita o Nome comum (por exemplo, o servidor FQDN ou o SEU nome). Você precisa digitar o nome do domínio associado ao seu servidor ou, mais provável, o endereço IP público do seu servidor.

      A totalidade dos prompt se parecerá com isto:

      Output

      Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:New York Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc. Organizational Unit Name (eg, section) []:Ministry of Water Slides Common Name (e.g. server FQDN or YOUR name) []:server_IP_address Email Address []:admin@your_domain.com

      Ambos os arquivos que você criou serão colocados nos subdiretórios apropriados em /etc/ssl.

      Passo 2 — Configurando o Apache para usar o SSL

      Criamos nossos arquivos de chave e certificado no diretório /etc/ssl. Agora, precisamos modificar nossa configuração do Apache para aproveitarmos melhor o mesmo.

      Vamos fazer alguns ajustes na nossa configuração:

      1. Criaremos um snippet de configuração para especificar configurações padrão robustas do SSL.
      2. Vamos modificar o arquivo SSL Apache Host Virtual incluso para apontar para nossos certificados SSL gerados.
      3. (Recomendado) Modificaremos o arquivo de Host Virtual não criptografado para redirecionar automaticamente as solicitações para o Host Virtual criptografado.

      Quando terminarmos, devemos ter uma configuração SSL segura.

      Criando um snippet de configuração do Apache com configurações de criptografia robustas

      Primeiro, vamos criar um snippet de configuração do Apache que defina algumas configurações do SSL. Isso irá configurar o Apache com uma série de criptografia SSL forte e habilitar algumas funcionalidades avançadas que irão ajudar a manter nosso servidor seguro. Os parâmetros que vamos definir podem ser usados por qualquer Host Virtual habilitando o SSL.

      Crie um novo snippet no diretório /etc/apache2/conf-available. Vamos nomear o arquivo ssl-params.conf para deixar seu objetivo claro:

      • sudo nano /etc/apache2/conf-available/ssl-params.conf

      Para configurar o Apache SSL com segurança, utilizaremos as recomendações de Remy van Elst presentes no site Cipherli.st. Este site foi projetado para fornecer configurações de criptografia de fácil acesso para softwares populares.

      [note ]As configurações sugeridas no site mostrado acima oferecem uma segurança robusta. De vez em quando, isso acontece ao custo de maior compatibilidade com o cliente. Se você precisa dar suporte a clientes antigos, existe uma lista alternativa que pode ser acessada clicando no link na página rotulada “Sim, dê-me uma criptografia que funciona com o software legado / velho.” Essa lista pode ser substituída pelos itens copiados abaixo.

      A escolha de qual configuração você usa dependerá em grande parte do que você precisa suportar. Ambas fornecerão uma ótima segurança.

      Para nossos propósitos, podemos copiar as configurações fornecidas em sua totalidade. Vamos fazer apenas uma pequena mudança. Vamos desativar o cabeçalho Strict-Transport-Security (HSTS).

      O pré-carregamento do HSTS proporciona maior segurança, mas pode ter consequências consideráveis se for habilitado acidentalmente ou de maneira incorreta. Neste guia, não habilitaremos essas configurações, mas você pode modificar isso caso tenha certeza de que você entenda as implicações.

      Antes de decidir, leia com cuidado Segurança de transporte estrito HTTP, ou HSTS, mais especificamente sobre a funcionalidade “pré-carregamento”

      Cole a configuração no arquivo ssl-params.conf que abrimos:

      /etc/apache2/conf-available/ssl-params.conf

      SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
      SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
      SSLHonorCipherOrder On
      # Disable preloading HSTS for now.  You can use the commented out header line that includes
      # the "preload" directive if you understand the implications.
      # Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
      Header always set X-Frame-Options DENY
      Header always set X-Content-Type-Options nosniff
      # Requires Apache >= 2.4
      SSLCompression off
      SSLUseStapling on
      SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
      # Requires Apache >= 2.4.11
      SSLSessionTickets Off
      

      Salve e feche o arquivo quando você terminar.

      Modificando o arquivo padrão de Host Virtual SSL do Apache

      Em seguida, vamos modificar o /etc/apache2/sites-available/default-ssl.conf, o arquivo padrão de Host Virtual SSL do Apache Se estiver usando um arquivo de bloco de servidor diferente, substitua seu nome nos comandos abaixo.

      Antes de continuar, vamos voltar para o arquivo de Host Virtual SSL original:

      • sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

      Agora, abra o arquivo de Host Virtual SSL para fazer ajustes:

      • sudo nano /etc/apache2/sites-available/default-ssl.conf

      Dentro, com a maioria dos comentários removidos, o arquivo de Host Virtual deve se parecer com isso por padrão:

      /etc/apache2/sites-available/default-ssl.conf

      <IfModule mod_ssl.c>
              <VirtualHost _default_:443>
                      ServerAdmin webmaster@localhost
      
                      DocumentRoot /var/www/html
      
                      ErrorLog ${APACHE_LOG_DIR}/error.log
                      CustomLog ${APACHE_LOG_DIR}/access.log combined
      
                      SSLEngine on
      
                      SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                      SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
      
                      <FilesMatch ".(cgi|shtml|phtml|php)$">
                                      SSLOptions +StdEnvVars
                      </FilesMatch>
                      <Directory /usr/lib/cgi-bin>
                                      SSLOptions +StdEnvVars
                      </Directory>
      
              </VirtualHost>
      </IfModule>
      

      Vamos fazer alguns pequenos ajustes no arquivo. Vamos definir as coisas normais que gostaríamos de ajustar em um arquivo de Host Virtual (endereço de e-mail do ServerAdmin, ServerName, etc., e ajustar as diretivas do SSL para que apontem para nossos arquivos de certificado e chave.

      Após fazer essas alterações, seu bloco de servidor deve se parecer com este:

      /etc/apache2/sites-available/default-ssl.conf

      <IfModule mod_ssl.c>
              <VirtualHost _default_:443>
                      ServerAdmin your_email@example.com
                      ServerName server_domain_or_IP
      
                      DocumentRoot /var/www/html
      
                      ErrorLog ${APACHE_LOG_DIR}/error.log
                      CustomLog ${APACHE_LOG_DIR}/access.log combined
      
                      SSLEngine on
      
                      SSLCertificateFile      /etc/ssl/certs/apache-selfsigned.crt
                      SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
      
                      <FilesMatch ".(cgi|shtml|phtml|php)$">
                                      SSLOptions +StdEnvVars
                      </FilesMatch>
                      <Directory /usr/lib/cgi-bin>
                                      SSLOptions +StdEnvVars
                      </Directory>
      
              </VirtualHost>
      </IfModule>
      

      Salve e feche o arquivo quando você terminar.

      (Recomendado) Modificando o arquivo de host HTTP para redirecionar para HTTPS

      Da forma em que se encontra, o servidor fornecerá tanto tráfego HTTP não criptografado quanto HTTPS criptografado. Para maior segurança, é recomendável redirecionar na maioria dos casos o HTTP para HTTPS automaticamente. Se não quiser ou precisar dessa funcionalidade, você pode pular essa seção com segurança.

      Para ajustar o arquivo de Host Virtual não criptografado para redirecionar todo o tráfego a ser criptografado pelo SSL, podemos abrir o arquivo /etc/apache2/sites-available/000-default.conf:

      • sudo nano /etc/apache2/sites-available/000-default.conf

      Lá, dentro dos blocos de configuração VirtualHost, precisamos adicionar uma diretiva Redirect, que direciona todo o tráfego para a versão SSL do site:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:80>
              . . .
      
              Redirect "/" "https://your_domain_or_IP/"
      
              . . .
      </VirtualHost>
      

      Salve e feche o arquivo quando você terminar.

      Passo 3 — Como ajustar o Firewall

      Se você tem o firewall ufw ativado, conforme recomendado pelos guias de pré-requisitos, pode ser necessário ajustar as configurações para permitir o tráfego SSL. Felizmente, o Apache registra alguns perfis com o ufw na instalação.

      Podemos ver os perfis disponíveis digitando:

      Você deve ver uma lista como essa:

      Output

      Available applications: Apache Apache Full Apache Secure OpenSSH

      Você pode verificar a configuração atual digitando:

      Se você permitiu apenas o tráfego HTTP regular mais cedo, seu resultado pode se parecer com este:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Para também admitir o tráfego HTTPS, podemos permitir o perfil “Apache Full” e então excluir a permissão de perfil redundante “Apache”:

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Agora, seu status deve se parecer com este:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Passo 4 — Habilitando as alterações no Apache

      Agora que fizemos nossas alterações e ajustamos nosso firewall, é possível habilitar os módulos SSL e de cabeçalhos no Apache, habilitar nosso Host Virtual pronto para o SSL e reiniciar o Apache.

      Podemos habilitar o mod_ssl, o módulo SSL do Apache e o mod_headers, necessário para algumas das configurações no nosso snippet SSL, com o comando a2enmod:

      • sudo a2enmod ssl
      • sudo a2enmod headers

      Em seguida, podemos habilitar nosso Host Virtual SSL com o comando a2ensite:

      • sudo a2ensite default-ssl

      Também precisaremos habilitar nosso arquivo ssl-params.conf, para que leia nos valores que definirmos:

      Neste ponto, nosso site e os módulos necessários estão habilitados. Devemos verificar e garantir que não haja erros de sintaxe em nossos arquivos. Podemos fazer isso digitando:

      • sudo apache2ctl configtest

      Se tudo for bem-sucedido, você receberá um resultado que se parecerá com este:

      Output

      AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message Syntax OK

      A primeira linha é apenas uma mensagem informando que a diretiva ServerName não está definida globalmente. Se você quiser se livrar dessa mensagem, é possível definir o ServerName como o nome do domínio do seu servidor ou o endereço IP em /etc/apache2/apache2.conf. Isso é opcional, uma vez que a mensagem não causará problemas.

      Se seu resultado tiver Syntax OK, seu arquivo de configuração não possui erros de sintaxe. Podemos reiniciar com segurança o Apache para implementar nossas alterações:

      • sudo systemctl restart apache2

      Passo 5 — Testando a criptografia

      Agora, estamos prontos para testar nosso servidor SSL.

      Abra seu navegador Web e digite https:// seguido pelo nome do domínio ou endereço IP do seu servidor na barra de endereço:

      https://server_domain_or_IP
      

      Pelo fato do certificado que criamos não ser assinado por uma das autoridades de certificado confiáveis do seu navegador, você provavelmente verá um aviso assustador como o que está abaixo:

      Apache self-signed cert warning

      Isso é esperado e é normal. Só estamos interessados no aspecto de criptografia do nosso certificado, não na validação de terceiros da autenticidade do nosso host. Em todo caso, clique em “ADVANCED” e então no link fornecido para prosseguir para seu host:

      Apache self-signed override

      Você deve ser levado para seu site. Se você olhar na barra de endereço do navegador, será possível ver um cadeado com um “x” sobre ele. Neste caso, isso significa apenas que o certificado não pode ser validado. Ela ainda está criptografando sua conexão.

      Se você configurou o Apache para redirecionar HTTP para HTTPS, também é possível verificar se o redirecionamento está funcionando corretamente:

      http://server_domain_or_IP
      

      Se o resultado for o mesmo ícone, isso significa que seu redirecionamento funcionou corretamente.

      Passo 6 — Mudando para um redirecionamento permanente

      Se seu redirecionamento funcionou corretamente e você tem certeza de que quer permitir apenas o tráfego criptografado, você deve modificar novamente o Host Virtual do Apache não criptografado para tornar o redirecionamento permanente.

      Abra mais uma vez o arquivo de configuração do bloco do seu servidor:

      • sudo nano /etc/apache2/sites-available/000-default.conf

      Encontre a linha Redirect que adicionamos mais cedo. Adicione permanent a essa linha. Isso muda o redirecionamento de uma redirecionamento temporário 302 para um redirecionamento permanente 301:

      /etc/apache2/sites-available/000-default.conf

      <VirtualHost *:80>
              . . .
      
              Redirect permanent "/" "https://your_domain_or_IP/"
      
              . . .
      </VirtualHost>
      

      Salve e feche o arquivo.

      Verifique sua configuração quanto a erros de sintaxe:

      • sudo apache2ctl configtest

      Quando estiver pronto, reinicie o Apache para tornar o redirecionamento permanente:

      • sudo systemctl restart apache2

      Conclusão

      Você configurou seu servidor Apache para usar uma criptografia robusta para conexões com clientes. Isso permitirá que você atenda aos pedidos com segurança e impedirá que agentes externos leiam seu tráfego.



      Source link