Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
It fails to validate on some clients because you do not send any intermediate certificates (the chain). I do not know how to do that on Azure but this is why it is failing. Use a site like this to see the missing chain. Use this same site with a website like this one to see what it should look like. https://decoder.link/sslchecker/loadbalancer.22dao.org/443
I still don't know I was hoping that was enough of a clue for you. Otherwise wait for an Azure expert to assist. I am going to change your title to signal that.
So I generated the certificates on a linux vm and then converted the pfx format using this conversation. Then I uploaded them to azure, so I think it has to do with the export/conversion process. Anything stand out?
This was the conversion command
sudo openssl pkcs12 -inkey <loadbalancer.pem path> -in <loadbalancer.cert path> -export -out loadbalancer.pfx
Generate your PFX with the ISRG Root X1 chain (not the default DST Root CA X3 which is not really valid on windows). If using certbot use the fullchain.pem file for your cert (this includes the intermediates). You also need to set a PFX password for it to be used on Azure.
If you can use Azure Key vault you can automated this with https://certifytheweb.com (the app I develop) - with that you would generate a certificate with a password (set under Certificate > Advanced > Signing & Security) and add a Deploy To Azure Key Vault task, then configure your gateway to pickup it's cert from Key Vault (if possible). That way, subsequent automatic renewals will push the new cert to key vault and keep the cert up to date (I think! I haven't tried Azure Gateway).