Thanks for asking question! As I can see that, the site is configured with IP SSL and while browsing to the default site URL, potentially, certificate corresponding to IP SSL binding may be returned instead of the default Azure certificate.
This scenario manifests itself when there are non SNI enabled clients hitting the website. This will cause all SNI bindings, including the default binding of WellaHealth.azurewebsites.net to fail as these URL's will return the IP SSL certificate
In order to rectify this, please ensure not to use SNI bindings along with IP SSL bindings and always browse to the website over custom domain URL if you have non SNI clients. In case you need to use SNI bindings, you need to ensure that the certificate that is bound to the IP SSL binding is issued to protect all configured URLs for the site (including the SNI bindings) and configure the same certificate against all other bindings. This behavior is by design.
Check this official document link on: If you have an SNI SSL binding to <app-name>.azurewebsites.net, remap any CNAME mapping to point to sni.<app-name>.azurewebsites.net instead (add the sni prefix).
Also suggest you refer this detailed blog on Breaking change for SNI-SSL hostnames on Azure App Service might be helpful.
Hope this helps. If you have further query or issue remains please let us know.