Question on this topic - is there a method of encrypting subdomains when you don't own the domain?
An example: I run a vm that exposes mysubdomain.azure.com, can I turn on ssl at that level? A google search says "no" but I figure this is a place where someone might have a workaround.
Each FQDN is treated separately, so generally speaking, if you can demonstrate control for a FQDN under an ICANN TLD, you can obtain a certificate.
Something you have to keep in mind are rate limits. Unless the (parent) domain owner has registered the domain in question as a public suffix[1], you, together with all other users who have subdomains under the parent domain, will be limited to 20 certificates per week.
Some domains, like for example the hostnames EC2 instances get that resolve to their public IP, have also been explicitly blacklisted because they are generally not assigned to anyone for longer periods of time, and it would be easy to mint certificates for a large number of those hostnames by just spawning tons of EC2 instances, which would make those certificates largely useless.
Finally, domain owners may decide to prevent issuance using a CAA DNS record, which are supported by Let's Encrypt.
Sure, LetsEncrypt can issue certificates for that domain. If you have a webserver you control that runs on port 80, you can use Certbot[1] to get a certificate for that domain.
[1]: https://certbot.eff.org/
It seems like LetsEncrypt should support that, per e.g. [1] - I haven't tried it myself, but I don't see any obvious howlers in that thread, or any a priori reason why it should not work given correct arguments to certbot and a service configuration that permits ownership verification to succeed.
It looks as though Azure itself also provides a CA [2], or at least resells one's services, for use with apps hosted on the platform. Depending on your needs, that may be a better alternative, though certainly it will also be more costly. It also appears [3] that the only route that service offers to satisfy the subdomain requirement is a wildcard cert, so there's that.
Each DNS zone (azure.com, mydomain.azure.com, otherdomain.mydomain.azure.com) is separate, and they can all be given independent TLS certs. The only relationship between azure.com and mydomain.azure.com, is that the azure.com name servers delegate DNS for mydomain.azure.com to the name servers of mydomain.azure.com.
So you can turn on encryption at that level, and using Let's Encrypt, the private key for your cert would be unique for you. So private keys for azure.com won't be able to decrypt traffic for mydomain.azure.com.
Afaik you would have to register a domain, and point alias.example.com to alias.azure.com via a CNAME record.
But for ssl etc to work you would also have to get your vm setup so it "knows it's own (new) name" (alias.example.com).
[you could also use an A record with the ip, but I'm guessing guaranteeing sub-domain.azure.com points to the right ip is easier that updating the ip on updates etc to the vm]
You can encrypt any subdomain at which you can serve an answer to Let's Encrypt's ACME Challenge [1][2].
That being said, I know they have a blacklist of certain domains. I've seen it once with amazonaws.com [3], and it's possible they have similar entries for azure.com, heroku, etc. They don't publicly release their blacklist.
I don't see why this wouldn't be possible, just tell Nginx (or whatever proxy) to serve one on 443 with appropriate TLS options and the root domain on 80. To a large extent subdomains are treated as different sites w.r.t. security. But it's possible Azure has some particular settings to make this impossible.
An example: I run a vm that exposes mysubdomain.azure.com, can I turn on ssl at that level? A google search says "no" but I figure this is a place where someone might have a workaround.