Siempre es bueno revisitar uno de los servicios mas queridos de Azure para mi: Azure Web Apps, con ellos (y SQL Database) empecé mi camino hacia la nube, fue blanco de mis primeros experimentos en lo que ahora se conoce como DevOps, y además… es el servicio donde tengo este blog, así que vamos a compartir experiencia que espero les sea de utilidad para configurar los sites que tenemos en este servicio.

Contextualizando, originalmente yo tenia este site en Blogger, el cual mude a WordPress con Azure Web Apps ya hace 8 años, cambiando su base de datos MySQL de clearDB hacia Azure hace 4, lo que no mencione es que originalmente este site solo uso el protocolo “http” por un buen tiempo, por lo que, como es sabido, terminaría siendo penalizado a nivel de SEO en los buscadores y generando desconfianza del lector, lo cual seria todo un problema de cara a los objetivos de divulgación de este sitio.

En ese sentido a poco de ingresar al programa MVP empecé a utilizar el beneficio de los certificados digitales de prueba que Digicert ofrece a la comunidad MVP, de esta manera ya tenia un certificado digital que podía vincular a mi site, indicando que la comunicación y el usuario viaja de manera segura, y… todo ha ido bien, pero este año decidí hacer una prueba cuyos resultados estoy probando y compartiendo ahora.

El detalle es que el proceso de generación de un certificado SSL en DigiCert es tedioso y poco claro,al menos hasta hace dos años se apoyaba en herramientas de apariencia casi 90era y no generaban de manera directa los archivos PFX que son los que acepta Azure Web Apps para instalar un certificado, así que este año cuando mi ultimo certificado de DigiCert cumplió sus dos años de vigencia, decidí probar una funcionalidad que Microsoft anuncio el 2019: los certificados SSL gratuitos para Azure Web Apps, funcionalidad que brinda un gran beneficio para sites sencillos como este pues existen algunas limitaciones, como por ejemplo el no poder usar wildcards (*), pero de todas maneras es una gran ayuda para el que tiene su dominio y quiere brindar seguridad a sus sites.

Ok, el caso es que yo usaba previamente un certificado wildcard de DigiCert, y todo estaba configurado alrededor de este esquema, tanto en Azure como en mi registro de dominios (en este caso Network Solutions) por lo que contare mas o menos como lo fui solucionando, esperando que le sirva tanto al que va a migrar como el que va a aprovechar esta funcionalidad por primera vez. Ojo, estoy dando por sobreentendido que ya se tiene la titularidad de un dominio, ya sea en GoDaddy, RCP, NetSol, etc, así como acceso a su respectiva consola y obviamente una subscripción en Azure.

Originalmente mi configuración en NetSol, era basicamente de esta forma en lo que respecta a Web (si, para configurar el servicio de correo hay configuraciones extras, pero eso no es el objetivo de este post): dos registros DNS de tipo A, uno para “@” y otro para “www”:

Y por el lado de Azure, para tener el comportamiento actual de que si alguien escribe “consultorinternet.com” automaticamente su navegador lo lleve a “https://www.consultorinternet.com” lo tenia configurado de esta forma:

Lo interesante es que en ese entonces ambas entradas estaban vinculadas al mismo certificado (este vinculo es el “binding” sobre el cual hablare al final), puesto que DigiCert te ofrece la opción de tener uno de tipo wildcard (en este caso uno de tipo *.consultorinternet.com), esto ya me asustaba un poco pues no estaba seguro de si funcionaria creando un certificado diferente por cada entrada, lo cual haria que en el peor de los casos deba crear un nuevo certificado wildcard de DigiCert, en fin … no esta mal tener un plan B, pero felizmente no hubo necesidad y ya veremos como fui solucionando los obstáculos.

Entonces quedaba claro lo que correspondía hacer, eliminar las entradas de los certificados de “consultorinternet.com” y “www.consultorinternet.com” reemplazándolas sucesivamente por nuevas versiones usando los nuevos certificados gratuitos, lo cual debía ser relativamente sencillo, bueno.. si y no.

Debo confesar que por experimentar decidí crear un nuevo certificado para “consultorinternet.com” sin haber borrado la entrada vigente, simplemente solicite agregar un Nuevo Certificado:

Luego de los cual, elegi uno del tipo “App Service Managed Certificate“, que es justamente el del tipo gratuito de Azure Web Apps, si hubiera querido usar uno de DigiCert hubiera tenido que elegir “Upload Certificate .pfx”.

Luego correspondía elegir a que dominio debía asignar este nuevo certificado, en este caso empecé por el padre: consultorinternet.com.

Y luego tocaba Validar, para luego Agregar, todo sencillo hasta aquí:

Como dije, con esto ya tenia dos certificados para consultorinternet.com, uno ya venciendo y otro listo para ser usado, era consciente de que iba a terminar borrando uno, pero tocaba replicar la misma experiencia con www.consultorinternet.com, lo cual parecia ser relativamente sencillo, seguir los mismos pasos: Intentar crear el nuevo certificado, determinar el host al cual asignarlo, validar, añadir, pero… resulta que luego de “Validar” y darle a “Add” uno tiene que esperar hasta que salga el respectivo mensaje, solo que en esta ocasión salio un mensaje que seria recurrente por un buen tiempo:

Buscando información encontré este enlace, donde al parecer aun teniendo registros CNAME se tenian problemas, pero que la solución era agregar en nuestros registros DNS una entrada CAA que referenciara a DigiCert, así que eso realizé, entrando a Network Solutions agregando este registro:

Por si acaso, aun no edite el registro CNAME, así que esperando unos minutos intente el proceso de creación del certificado, y… siguió saliendo el error mencionado, uuy así que no quedaba mas remedio que crear el CNAME respectivo de esta manera:

El problema es que un registro CNAME no puede convivir con un registro A, por lo que no quedo mas remedio que borrar el registro A para “www”, que curiosamente apuntaba a una IP, para recién entonces poder crear mi flamante registro CNAME apuntando a consultorinternet.azurewebsites.net, así que espere unos minutos e intente repetir el proceso desde Azure y… error nuevamente, ya me veía teniendo que reiniciar todos mis datos en NetSol y/o eventualmente ir por todo el proceso de registro en DigiCert, pero me fui a almorzar y una hora después funciono!! al parecer en este caso los registros DNS tardaron en propagar sus cambios.

Ok, ahora lo que correspondía era vincular mis flamantes certificados a los respectivos dominios, por lo que desde Custom Domains hice clic a “Add Binding”, así:

Listo, todo operativo, la pagina funciona como lo estas comprobando al navegar por aquí, así que ahora vamos por las conclusiones:

• Los certificados SSL gratuitos de Azure Web Apps son una gran alternativa para quien no tiene necesidades complejas, como por ejemplo un site de comercio electrónico, en ese sentido si recomiendo ir por un certificado “completo”, esto debido a que solo garantiza la seguridad de la comunicación, mas no el ownership del certificado.
• Como consecuencia del no soporte a certificados wildcard *, es necesario usar dos certificados gratuitos, lo cual no es un gran problema.
• Por alguna razón estos certificados exigen un registro CNAME para el “www” y no permiten usar un registro A para este propósito, lo curioso es que para el “@” el registro de tipo A funciona perfectamente, no debiendo hacerse cambios en ese sentido.

Espero que les haya sido de utilidad, a mi me ha hecho aprender mucho, siendo este post muy especial, pues es el primero que escribo como Microsoft MVP para Azure (en adición a Developer Technologies). Espero sus comentarios!