Share on Google+Share on FacebookTweet about this on Twitter

le-logo-wide

Llevo ya un tiempo queriendo escribir algunas palabras sobre esto por dos motivos. El primero, debido a la gran importancia que a día de hoy debería de ser mantener las comunicaciones seguras entre los equipos de los usuarios y los servidores remotos, y en segundo lugar por lo que, desde mi opinión claro está, es la gran labor que han llevado a cabo y están realizando todos los que están detrás del proyecto de “Let’s Encrypt”.

Como es costumbre, vamos a hacer una pequeña introducción para explicar en primer lugar un poquito de todo esto para quienes no sepan de ello, y para los que sepan y aun estén recelosos clarar algunas dudas.

 

¿Que es Let’s Encrypt?

La versión corta y reducida es la que podemos encontrar en su propia web: https://letsencrypt.org/:

“Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open” (Let’s Encyrpt es una nueva Autoridad de Certificación. es gratuito, automatizado y abierto).

Internet no se construyó en su origen para ser seguro, de tal modo que en su versión simplista se trataba de poder enviar información desde un punto a otro. Los años, y más los tiempos que corren, demostraron que eso está muy bien, pero se hacía necesario algún sistema de cifrado punto-a-punto que asegurase dicha comunicación. Los cifrados punto-a-punto se denominan así (ahora de moda con las aplicaciones de mensajería instantánea) porque el contenido se cifra/descifra en los extremos, es decir… se cifra en nuestros dispositivos y circula de ese modo hasta llegar al destino, haciendo que sea, en teoría siempre, poder “leer” dicho tráfico si alguien intercepta la comunicación en cualquier punto de dicha travesía. De este modo tan solo el origen y el destino de dicha comunicación podrían entender lo que están enviando/recibiendo. Esto fue vital para Internet, y así nació HTTPS, que todos estamos hartos de ver.

HTTPS se fundamenta en el uso de los protocolos TLS y SSL, los cuales a su vez su funcionamiento radica en el uso de lo que llamamos certificados digitales para poder crear un entorno de cifrado asimétrico (ya sea RSA, ECC…). Esto ya hablé bastante en su día, así que no voy a repetir el grueso de todo aquello, quien le interese, creo que estaba en el artículo de Seguridad: Encriptación y Autentificación (cap 4). Abreviando mucho, digamos que, al menos, el servidor al cual los usuarios se conectan para iniciar su comunicación de forma segura debe de poseer un certificado digital que será enviado al cliente al iniciar la conexión y que le dará a este toda la información necesaria para realizar esa conexión, como la clave pública que usará el cliente para cifrar la clave simétrica de sesión, los algoritmos a usar para el cifrado… e igualmente importante, los datos necesarios para que el usuario PUEDA VERIFICAR LA CORRECTA IDENTIDAD DEL SERVIDOR AL QUE SE CONECTA, empezando por el CA (Autoridad de Certificación) que emite dicho certificado.

El cifrado es esencial si queremos que nuestras comunicaciones no puedan ser leídas en ningún punto hasta su destino (evidentemente sobre todo cuando estamos transmitiendo información que pueda ser confidencial o importante como usuarios/contraseñas, tarjetas de créditos, datos personales..). Esto no es un problema para TLS/SSL, y a día de hoy si la implementación TLS/SSL es buena y usando las versiones más actuales y otros, el cifrado es, en la práctica, imposible de romper (no vamos a entrar en teoría de computación cuántica, errores de implementación, ataques de tiempo y otros). Pero el cifrado es solo la mitad del problema, porque nada podría impedir igualmente a quien quisiese interceptar la comunicación, suplantar el servidor destino haciendo de “hombre en medio” y mandar su propio certificado al usuario, creyendo este que es legítimo, y por otro lado este atacante se comunicaría hacia el servidor real, y como el es en ambos casos extremo de la comunicación, podría leer perfectamente toda la información cifrada tanto por uno como por otro. Incluso como muestra la siguiente imagen, se podría hacer uso de esto con fines igualmente legítimos: (Nota: La imagen está sacada de otro sitio, no tenía ganas de hacer una similar)

interceptionproxy

Este esquema muestra el problema que indicaba. Un cliente podría querer comunicarse con el servidor remoto www.example.com, pero un tercero que quisiese interceptar la comunicación (aka SSL Interception proxy) podría enviar su propio certificado (emitidio por Corporate CA) al cliente, recibir la comunicación por parte de este, y a su vez conectarse al servidor remoto real, que le enviaría su certificado real (emitido por Real Public CA) para reenviar lo que el cliente le mandase a él. Todo iría cifrado, desde el Cliente al intermediario, y del intermediario al servidor final. Problema?? Que realmente no sería un cifrado punto-a-punto, ya que en medio se habría colocado un tercero que podría estar leyendo absolutamente todo el tráfico que pasase por él.

¿Como se soluciona esto? Aquí es donde radica todo. La solución es que los clientes, cuando usan cualquier aplicación para conectarse a servidores remotos por conexiones seguras TLS/SSL (ya sea un navegador web, un gestor de correos, una aplicación de mensajería instantánea, un juego, un…) posee una “base de datos” propia que puede venir con el sistema operativo o con la propia aplicación, en la que se especifica claramente que Autoridades Certificadoras se aceptan como seguras. Realmente lo que contiene dicha base de datos son los certificados públicos de todos los CA válidos.

Así pues, si nuestro navegador web solo tuviese en su base de datos como CA a la FNMT (por poner un ejemplo), tan sólo los certificados emitidos por el certificado Raiz de la FNMT (o los secundarios que dependan de este si lo tienen permitido), serán validados y dados por bueno por el navegador del usuario, de lo contrario el navegador directamente nos pondrá en aviso, denegando por defecto la conexión. En el ejemplo anterior, el cliente quiere acceder al servidor www.example.com y lo que recibe es un certificado emitido por un tal “Corporate CA)” que dice ser el certificado de www.example.com. Si el cliente posee dicho CA en su base de datos como autoridad válida, no habrá problemas porque el cliente confía en que los certificados emitidos por dicho CA se pude confiar en ellos, y la comunicación se hará sin problemas. PERO!! Si la base de datos del cliente no tiene ninguna constancia del CA en cuestión, o el certificado que posee la base de datos del cliente del CA difiere al que el emite… la conexión muy probablemente no se realizará.

Eso significa que al final, además del cifrado hace falta la cuestión de confianza, que en última instancia viene dada por el CA que emite dicho certificado.

¿¿Que es Let’s Encrypt?? Un CA, ni más ni menos. Actualmente actúa como CA “intermedio”, no posee un certificado Raiz que sea “universalmente” aceptado, y depende de la generosidad en este caso de IdenTrust, que es el certificado Raiz, que a su vez emitió el Certificado CA de Let’s Encrypt que permite a estos emitir certificados. Por poner un ejemplo de si esta práctica es habitual o no, todos los certificados que usa Google usan esta misma política, Google no tiene certificado raiz propio, sino que su certificado CA intermedio está emitido/firmado a su vez por GeoTrust.

Pero hay cientos o miles de CA, ¿cual es su importancia?

 

El principal problema con los certificados digitales

Lo ideal es que el 100% de todas las comunicaciones fuesen cifradas punto a punto, en cambio el uso por servicios/webs es muy bajo en comparación al tráfico sin cifrar. ¿Por qué?

Bueno es simple. Cualquiera puede crear en cuestión de segundos un certificado digital para su empresa, para firmar código, para un servidor web… se tardan segundos, pero dicho certificado sólo será creíble de puertas para fuera si está emitido por un CA de confianza. Así que eso sólo deja dos opciones:

A) Convertirnos nosotros mismos en un CA de confianza y emitir los certificados que queramos.
B) Obtener el certificado que queremos usar de un CA de confianza

La opción A se antoja cuanto menos casi imposible. Llamamos un CA de confianza, básicamente a un CA que es universalmente reconocido por la gran mayoría de todos los desarrolladores, empresas y otros que hacen uso de certificados, evidentemente empezando por las empresas que están detrás de los navegadores Webs, de los Sistemas operativos… Es decir, que si cualquiera quisiera crear una empresa que se dedicase a actuar como CA, además de toda la infraestructura de emisión, revocación… tendría que ir solicitando prácticamente uno a uno la inclusión de su CA en el software/hardware del desarrollador/fabricante que fuese, y estos a su vez aplicarían y obligarían a cumplir con las normas más estrictas de privacidad y seguridad que estimen. Es un proceso muy largo (años perfectamente), y como digo no existe una base de datos oficial universal, sino que cada desarrollador/compañía mantiene aquellos CA que estima.

Como sencillo ejemplo, pongo por caso el problema que tenemos aquí en España con el DNI electrónico o los certificados CERES. Ni la FNMT que lleva muuuuchos años emitiendo certificados (y hablamos de una entidad totalmente seria, respetable y a nivel nacional) ha logrado ser incluido como un CA de confianza. Sólo hace unos días precisamente, han logrado por fin la inclusión en Mozilla, y después de al menos de 2 años de trabajo y ajustes de todo tipo en sus infraestructuras para tener la luz verde de Mozilla. Y eso tan solo se aplica a Mozilla (Firefox, Thunderbird…), porque si la FNMT quiere que Google o Microsoft incluyan su certificado, deben de solicitar su inclusión de forma similar a la que hicieron con Mozilla, y de nuevo someterse a todos los controles de estos. Como actualmente ese CA no está en nuestros navegadores, todos hemos sufrido aquí montones de veces lo que sucedía cuando accedíamos a páginas de las propias instituciones Españolas: Certificado no válido, error de comunicación… por qué?? Porque los certificados que usan son emitidos por CA que no están por así decirlo universalmente aceptos, así que es necesario instalar manualmente los certificados de dichos CA, especificando que dichos CA serán válidos para nosotros.

Actualmente, Let’s Encrypt tiene ya el visto bueno a su vez de la gran Mozilla, lo cual es un inmenso salto, y en conversaciones con Google/MS para sus respectivos navegadores/plataformas/software. Como he dicho actualmente actúa como CA intermedio, ahora busca independencia total, pero eso, aun teniendo ya luz verde por Mozilla, será un camino largo. Aun con todo, para tener en cuenta lo complicado que es esto, ni siquiera aquellos que incluyen tu CA como CA Raíz te dan un cheque en blanco, son necesarias auditorias externas cada X, especificar bien claro el uso que se le va a dar y que limitaciones, que tipo de certificados va a emitir… y aun con todo en cualquier momento, si de detecta cualquier fallo que los desarrolladores/compañías estimen, ni que decir tiene que la supresión del CA Raiz sería inmediata.

Pero es que la importancia es capital. Tener un certificado CA, ya sea Raiz reconocido (cosa muy muy compleja) o tener un CA intermedio firmado por un CA raíz, implica poder, en teoría claro está, emitir los certificados que se quisiesen para la tarea que se quisiese y para los dominios que se quisiese. Es decir… el sueño de cualquier Hacker, ya que con uno en su poder cualquier ataque de interceptación de tráfico por ejemplo, sería extremadamente efectivo y sencillo, y también simplificaría mucho los engaños y sitios fraudulentos. Así que es normal que las grandes no se tomen eso de admitir un CA Raíz así como así.

 

La opción B es la que a día de hoy hace uso el 99% de todos. En realidad tan solo las grandes instituciones, multinacionales o empresas que se dedican precisamente a la emisión de certificados, optan o pueden optar por la opción A, todos los demás lo que hacemos es obtener certificados emitidos por los CA de confianza, o en el caso de grandes empresas en todo caso lograr un CA intermedio (auditado y vigilado) por lo general para emitir sus propios certificados. En principio, cualquiera puede solicitar sin ningún tipo de problema un certificado a un CA para el uso que estime, ya sea un servidor Web, firmar código o lo que sea. Aquí nos vamos a centrar a servidores Web por ser además el uso mayoritario. La pregunta entonces se derivaría, una vez descartada la opción A, en cual es el motivo entonces, si virtualmente cualquiera puede solicitar un certificado a un CA de confianza: Dinero, el más viejo y conocido de todos, el señor billete, Cash, Money.

 

Tipos de Certificados (para Servidores Web)

A día de hoy existen básicamente 3 tipos de certificados para servidores Web, que se diferencia en función de la información que el cliente quiere por así decirlo validar ante el CA. Como al final todo es una cuestión de confianza, cuanta más información te valide el CA sobre tu persona/empresa, más fiabilidad dará dicha persona/empresa de cara a todo el mundo:

 

-Certificados de Validación de Dominio (DV):

Actualmente más del 60% de todos los certificados que podemos encontrar en la web corresponden a este tipo. El CA que lo emite sólo valida/garantiza que es emitido para el dominio en cuestión, sin aportar absolutamente ninguna otra información identificativa de dicho dominio. Es decir, por lo general basta ser tan solo el dueño o el administrador de un dominio para poder cumplir con los requerimientos que pueda exigir un CA en la emisión de un certificado de este tipo. Ojo!! Eso no significa que estos certificados sean malos, ni mucho menos, aunque se ha hecho muy mala prensa de ellos, pero por cuestiones principalmente de marketing indigno por parte precisamente de los propios CA para que los clientes adquieran certificados que veremos a continuación… que son mucho más caros.

Si visitamos una web, cualesquiera, accedemos por HTTPS y el certificado está validado por un CA de confianza, aun siendo de tipo DV podemos tener la certeza de que el certificado es de quien dice ser. Si un atacante intentase replicar dicho certificado e intentase usar el dominio original, tendría que poder controlar y tener acceso a la configuración del propio dominio para poder lograr un certificado emitido por un CA de confianza, de lo contrario aunque su certificado dijese que es para la web en cuestión, dicho certificado sería rechazado por los navegadores, aplicaciones… del cliente. Esto es importante, porque precisamente hace relativamente poco se culpaba a este tipo de certificados a que se había logrado realizar un ataque a gran escala, pero de nuevo el artículo era sesgado y creado por un CA de prestigio para desprestigiar a otros, si un atacante logra hacerse con el control total de un dominio, da igual al CA de confianza que acuda para la emisión de un certificado DV, porque se lo darán sin problema.

Los certificados DV, a efectos visuales, estamos hartos de verlos en los navegadores web: Candadito Verde, sin más.

certificado DVPor supuesto, siempre suponiendo que son emitidos por un CA válido, de lo contrario tendríamos advertencias de seguridad, candadito rojo o cualquier otro identificativo.

Certificado Info DV

-Certificados de Validación de Organización (OV):

Son el segundo grupo de certificados más usados en la actualidad, y en realidad muy similares a los DV. El CA en este caso emite los certificados no solo validando por los medios oportunos el dominio, sino que además solicita información adicional de la organización/empresa que hay detrás de dicha solicitud, lo que hace necesaria la aportación como es lógico de documentación legal y otros, necesario para que el CA pueda verificar la autenticidad de dicha empresa/organización.

No obstante a efectos visuales para el usuario son prácticamente iguales a los DV, y sería necesario mirar el Certificado directamente para ver la diferencia, que radica en que este tipo de certificados incluye en su variable O (Organization) precisamente la compañia a la que pertenece. En las dos pantallas que puesto anteriormente, no se podría saber si el certificado que he puesto es un DV o un OV, ambos tendrían el mismo aspecto.

Un ejemplo sencillo de certificado OV es el de Google: https://google.es. Pero sería necesario acceder al certificado en cuestión para ver que efectivamente está verificada la organización:

Certificado OV

Si nos fiajos en la pantalla de la derecha, Google Inc. está incluido dentro de la variable O del certificado, aunque sólo es visible si accedemos al visionado directo del certificado. En este caso particular vemos si miramos un poco mas abajo información del propio emisor (CA) del certificado, y básicamente se repite porque Google a su vez es un CA universalmente reconocido, con lo que evidentemente emite sus propios certificados. Cabe indicar que Google no es en sí un CA raiz, OJO!! A su vez depende del certificado Raiz de GeoTrust, aunque Google puede emitir sus propios certificados. Pero la parte que nos atañe aquí es el primer bloque.

 

-Certificados de Validación Extendida (EV):

Son como es natural los más caros, e igualmente los que en teoría ofrecen el mayor grado de confianza para los usuarios. En este caso el CA deberá de verificar mucha más información relevante sobre la propia compañía, siendo el proceso de verificación mucho más lento y profundo. La finalidad es clara, que el usuario final tenga la plena y total seguridad de que la web a la que está accediendo es 100% confiable. Aun con todo al final siempre es todo muy relativo, porque en cuanto a seguridad se refiere podría dar la misma seguridad un certificado tipo DV y OV. Si los certificados EV se crearon exclusivamente por cuestiones de marketing y como excusa de embolsar más dinero para los CA, lo dejo en manos de los lectores. En lo personal, aunque por supuesto estoy totalmente de acuerdo a que la fiabilidad que pueda otorgar un certificado EV es como es natural mayor a un certificado DV, eso no implica que un certificado DV no me de confianza alguna.

Está claro que un hacker, aun logrando acceso y control al dominio le sería virtualmente imposible o cuasi imposible lograr que emitiesen para el otro certificado EV para un subdominio de dicho dominio o cualquier cosa similar, o intentar crear una web con nombre similar e intentar que la organización y otra información pusiese en el certificado que es otra que se quiere suplantar. Eso es evidente, cuantos más controles sometan los CA a los clientes para emitir el certificado, este será más  confiable, pero lo siento… no soy de esos que aconseja por ello que cualquier tienda tenga que tener por obligación un certificado EV, como si hacen la mayoría de todos los CA (teniendo en cuenta que el precio es mucho mucho mayor)

En este caso, los certificados EV no obstante si son tratados de un modo más… especial por los navegadores Webs. Son muchas menos web en los que los hemos visto, pero no son extraños a día de hoy encontrar algunas webs sobre todo que los usan (curiosamente, muchas de ellas son empresas que actúan también como CA). Uno de los ejemplos más “estrella” de ello, es la archiconocida PayPal, que desde luego pocos sitios han sufrido más intentos de phising y SCAN. Podemos saber perfectamente si es un certificado EV porque la propia barra del navegador web cambia para mostrar una barra adicional verde que incluye directamente la información de la propia compañía:

Certificado EV

Esa “barra verde” que hace acopio en este caso Firefox automáticamente nos dice que estamos ante un certificado EV, y ni siquiera hace falta acceder a la información del propio certificado para ver que directamente nos da la información en el propio Firefox sin ir mas profundamente, mostrando la compañía e incluso la dirección de esta.

Muchos se preguntarán que por qué Google u otros grandes como Facebook no usan este tipo de certificados. Bien, oficialmente no existe una respuesta ante esto por sus partes, pero desde mi punto de vista es obvio, y viene a colación de lo dicho anteriormente. Los certificados EV, pese a mostrar más información directamente en los navegadores y que los CA necesiten más datos para emitirlos, no aportan por sí mismos nada más, no dan más seguridad ni más nada, sino que son un reclamo al público para decir: “Ei, mira, uso un certificado EV, tienes que fiarte de mi”. O por ejemplo: “Ei, ves?? Soy el mas guay y el mejor porque uso el certificado EV”. Google tiene nombre propio y en mayúsculas, su propia marca es él mismo y no hay persona que tenga un PC que no conozca quienes son. Evidentemente para ellos no es cuestión de dinero.

Como dije antes y lo reitero, que cada cual saque sus propias conclusiones sobre la necesidad, o no, de que los sitios como tiendas de comercio electrónico y otros requieran un EV, o les sea más que suficiente con un OV. No tiene nada que ver con la seguridad/cifrado, es sobre todo una cuestión de marketing, tanto para los CA que los venden, como para aquellos que quieren parecer mejores por tenerlos. No estoy en contra de los certificados EV, son importantes en muchos casos, pero la gran mayoría están movidos o por el propio marketing que quieren hacer ellos mismos para con el público, o por desconocimiento de quien los adquieren. Como siempre… es mi opinión.

 

 Let’s Encrypt

Bueno, y ¿qué tiene que ver todo esto con Let’s Encrypt?. Básicamente, que Le’ts Encrypt ha sido la primera iniciativa real y usable de que prácticamente cualquiera que tenga un dominio/hosting mínimamente decente, poder adquirir un certificado válido emitido por un CA de confianza (en este caso Let’s Encrypt, aunque de momento actúa por encima de ellos el certificado Raiz de IdentTrust), sin siquiera invertir un solo euro, y de manera además totalmente transparente, es decir… toda infraestructura que usan es de código abierto y puede verificarse, cumpliendo con todos los requisitos de seguridad que puedan cumplir igualmente cualquier otro CA. Eso sí, OJO, Let’s Encrypt SOLO EMITE CERTIFICADOS DV.

Para poner todo esto un poco desde cierta perspectiva. Tomemos los precios por ejemplo de un CA conocido como pueda ser Godaddy (iba a coger Symantec pero los preciso son mucho mayores.). Evidentemente estos datos no son extrapolables a otros CA, cada uno tiene sus propios precios, tomo los de Godaddy por ser relativamente conocidos y porque sus tablas de precios son muy claras. Sus precios anuales (redondeados) para un solo dominio sin incluir subdominios son los siguientes:

-Certificado DV: 85€
-Certificado OV: 110€
-Certificado EV: 227€

A nadie se le escapa que si quisiésemos por ejemplo un certificado que cubriese también todos los subdominios la gracia se nos iría a 330€ en el caso de los DV (siempre tomando de ejemplo los precios de Godaddy. Sí, prácticamente todos los CA que “venden” certificados garantizan con un seguro el certificado, pero no dejan de ser precios importantes a desembolsar de manera anual. No estoy en contra para nada de este tipo de certificados, no estoy endemoniando a Godaddy, Symantec, Comodo… para nada, ojo, son empresas en su mayoría muy profesionales y con grandes servicios, solo quiero poner en perspectiva todo el asunto que nos trae.

¿Que sucede? Pues que evidentemente una empresa no tiene problema en gastarse en sus presupuestos uno dos o los certificados que necesite, sean DV o incluso si se quieren dar la fardada y la presuntuosidad EV. ¿Pero que pasa con las Pymes?? ¿Que pasa con bloggers, autónomos y básicamente el gran grueso de la población? Que costearse incluso un certificado DV puede ser costoso para el poco uso que creen poder darle, y eso acompañado al desconocimiento es lo que hace que a día de hoy má del 60% de todas las web no soporten HTTPS. Y el problema por supuesto se multiplica si lo que se requieren son certificados wildcard/multiples subdominios o múltiples dominios.

Let’s Encrypt por otro lado, como digo, ha hecho posible que prácticamente cualquiera tenga acceso a certificados DV, sin importar el número de subdominios que se requieran o el número de certificados a necesitar por poseer múltiples dominios. Se ha criticado que el proceso sea relativamente automático, pero no nos engañemos… todos los CA usan procedimientos igualmente automatizados para ello (certificados DV), pero de nuevo es normal, a fin de cuenta una organización sin ánimo de lucro alguno está ofreciéndote los certificados DV que quieras a tus dominios y subdominios.

Por supuesto, no es oro todo lo que reluce, y Let’s Encrypt (a partir de ahora LE) puede no ser la mejor opción para todos. Vamos a ver que puntos son o deberían de ser de gran interés para el usuario:

-LE sólo emite certificados DV
-LE sólo emite certificados de 3 meses de vigencia (es lo habitual por otro lado, pero eso obliga a automatizar el proceso de renovación/instalación)
-LE requiere que tengamos como es normal acceso y control sobre el dominio, y si queremos que sea sencillo acceso root en el hosting en cuestión, de lo contrario el proceso puede ser más complicado.
-Muchas compañías de Hosting NO PERMITEN este tipo de certificados por cuestiones obvias, ellos mismos los venden. Aunque cualquier servicio de hosting en el que tengamos acceso al propio servidor como Root no debería de ser problema. Por suerte, y dada la gran aceptación que ha tenido muchas empresas de hosting de siempre están viéndose obligadas a permitir de forma “sencilla” su uso y su automatización completa.
-LE requiere que se tenga por lo general un conocimiento mínimo de que estamos haciendo, de que es un certificado digital y de como usarlo.

 

No obstante tampoco es tan malo como lo pitan algunos:

-LE permite emitir usar tanto certificados RSA como ECC (certificados mas pequeños, y más seguros)
-LE instalado correctamente permite automatizar todo el proceso de forma sencilla, con lo que la renovación no es un problema
-LE Es totalmente gratuito
-LE actualmente usa actualmente un certificado Raiz que generosamente les emitió un certificado intermedio para poder hacer funcionar la cosa, actualmente YA TIENEN el certificado propio CA Raiz aceptado por Mozilla (un gran paso), con lo que a medio-largo plazo serán incluso un CA de confianza de todo derecho.
-La gran aceptación ha “obligado” a grandes como Godaddy, OVH, WordPress… permitir su uso o directamente o indirectamente. Otros por desgracia como 1and1 y algunos otros, de momento al menos, no tienen intención. Siempre como digo en alojamientos web “estándares”, ya que cualquier servicio de hospedaje “completo” tipo servidores virtuales o dedicados, deberían de poder usarlos sin problema alguno.

 

Instalación/Uso

Esto me temo que depende enormemente de donde y como se quiera realizar. En su versión más simplista, suponiendo un control completo del propio servidor. Lo más simples es el propio “cliente” que aconseja Le, llamado Certbot, que tienen instrucciones sencillas para su instalación prácticamente en cualquier distribución linux y servidor Web que se use. Teniendo en cuenta la gran variedad, es obvio que no voy a explicar como donde y cuando.

No obstante, y con la idea en mente que pueda ser usado en la mayor cantidad de sitios posibles, se han creado diferentes clientes muy dispares que aprovechan las diferentes opciones de verificación de dominios que obliga, como es natural, LE para la expedición de los certificados. Así por ejemplo, CertBot requiere que se posean permisos de administrador, mientras que las herramienta acme.sh (hay otras) que podemos encontrar AQUI permite su instalación y uso sin necesidad de Root, aunque pueda ser necesario como es natural instalar uno mismo los certificados donde correspondan

Así tenemos muchos hospedajes Web “baratos” en el mercado que no permite root en sus servidores pero si especificar los certificados TLS. Gracias a herramientas como Acme.sh se pueden ejecutar por SSH en los servidores, lograr que LE nos expida los certificados y posteriormente instalarlos en los paneles de control que nos permita el proveedor. Quizás no es en este caso 100% automatizado, pero si hace que sea viable su uso, que a fin de cuenta es lo que importa. A medida que más proveedores se usan, más sencillo será tanto para administradores como para los propios chicos de LE automatizar las expediciones e instalaciones, y no dudarlo, mejorar con creces la seguridad global dentro de Internet.

 

Conclusión

Al final la idea es la misma: Que aquellos administradores o pequeñas/grandes empresas donde no se han usado certificados para asegurar el tráfico por HTTP por motivos económicos o por infraestructuras, les sea rentable y lo más sencillo posible. Esto no quiere decir que los certificados de cualquier otro CA tengan menos valor, repito. LE no es para todos, y lo comprendo. Pero eso no quita que alabe la gran idea y el gran trabajo que están realizando, y que sirva igualmente de tirón de orejas al resto de CA que hasta ahora han podido imponer un poco los precios que han querido, a fin de cuenta quien se iba a meter en emitir certificados desde un CA reconocible de forma gratuita.

Recomiendo a cualquiera que tenga dominio/hospedaje propio al menos informarse un poco al respecto, merece la pena, y que se plantee realmente si es viable o no su uso en cada caso. En lo personal lo tengo claro… quitando casos concretos, todos los dominios y otros que pueda gestionar irán poco a poco usando certificados de LE, siempre que crea que es necesario claro, gran prueba es que este mismo blog no solo no va sobre HTTP plano sino que no tiene opción (actualmente). Forzar HTTPS en cualquier sitio que pueda enviar información confidencial de ida o vuelta es mandatorio, al menos desde mi punto de vista, y más aun cuando hay datos sensibles. Un DV suele ser más que suficiente para la gran mayoría de casos, así que no hay motivo para no tomar LE muy muy enserio como opción.

Y sí, aunque theliel.es aun no está “asegurado”, ya empecé hace unas semanas con la implementación de LE en todos los dominios que están bajo mi control, que no son pocos, aunque eso no quiera decir que fuerce las conexiones HTTPS por defecto en todo momento. A fin de cuenta los procesos es mejor hacerlos poco a poco…

Desde aquí, aunque posiblemente no me lean, sólo dar la enhorabuena al trabajo que están realizando, creo sinceramente que es de esas iniciativas que sí cambian las cosas.