1

currently I want to connect a Cosmos DB instance, which is behind a service endpoint of a Subnet with an Application Gateway instance, which is behind another subnet.

Therefore I implemented a Https forward from an public IP to the Cosmos DB instance. However, the azure portal tells me that the DB is an unhealthy backend service and says that the certificate is not white-listed: enter image description here

These are the steps I done so far:

  1. Create a TLS certificate for the connection from the App Gateway tot the Cosmos DB, where the Common Name (FQDN) is equal to to the URI of the Cosmos DB isntance in the Overview (example.documents.azure.com):

$ openssl genrsa -out priv-key-db.pem 4096 $ openssl req -new -key priv-key-db.pem -out csr-db.pem $ openssl x509 -in csr-db.pem -out cert-db.cer -req -signkey priv-key-db.pem -days 365

  1. Upload the .cer file while creating an appropriate http-rule in the azure portal: enter image description here
Lau
  • 1,353
  • 7
  • 26

1 Answers1

2

The Azure Cosmos DB is an Azure managed service. We access it via HTTPS with the public cert issued by Baltimore CyberTrust Root. I don't think you can create a TLS certificate for the connection when you access the DB instance via application gateway because if you want to do this, you also need to bind the TLS cert to the Azure Cosmos DB service, otherwise, probes fail and the back end is not whitelisted.

From step 7 - Upload the certificate to be used on the SSL-enabled back-end pool resources.

The default probe gets the public key from the default SSL binding on the back-end's IP address and compares the public key value it receives to the public key value you provide here.

If you are using host headers and Server Name Indication (SNI) on the back end, the retrieved public key might not be the intended site to which traffic flows. If you're in doubt, visit https://127.0.0.1/ on the back-end servers to confirm which certificate is used for the default SSL binding. Use the public key from that request in this section. If you are using host-headers and SNI on HTTPS bindings and you do not receive a response and certificate from a manual browser request to https://127.0.0.1/ on the back-end servers, you must set up a default SSL binding on the them. If you do not do so, probes fail and the back end is not whitelisted.

As a workaround, you might use some third party proxy server to help redirect the HTTPS traffic to your backends such as Nginx. Hope this could help you.

Nancy
  • 26,865
  • 3
  • 18
  • 34
  • Ok, wouldn't it be possible if I Download the ``.crt`` from [Baltimore CyberTrust Root](https://www.digicert.com/digicert-root-certificates.htm) and convert it to ``.cer``. Or do I oversee something here? – Lau Jul 26 '19 at 08:55
  • I have tried to do it but I can not get a pfx file since we could not get the private key from the web browser. For end to end SSL, we need a .pfx cert and a .cer cert. – Nancy Jul 26 '19 at 09:03
  • I think I only have to upload the certificate.cer under the HTTP settings page, which will white-list the backend. So no private key is needed. In my understanding the .pfx is needed for the endpoint of the APP Gateway to authenticate as server. I`ll try it later. – Lau Jul 26 '19 at 09:06
  • I did so and now I get a different error message :D But it seemed to work. Do you work for the MS Support? I opened a ticket with our Premier Support, but no one responded. I would close it then. – Lau Jul 26 '19 at 09:41
  • However, can you recommend an alternative to App Gateway, that I can set in front of the Cosmos DB? – Lau Jul 26 '19 at 10:17
  • 1
    Have a look at [azure front door service](https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview) – Nancy Jul 26 '19 at 10:29
  • Sorry, but Azure Frontdoor can not route to VNET, but my Cosmos DB has to be connected via a service endpoint. So may I try a load balancer. – Lau Jul 26 '19 at 13:36