1

I'm not too comfortable with these things, but quite possibly what I'm asking is trivial.

I have a site hosted at foo.azurewebsites.net

And also an API at bar.azurewebsites.net (WEB API as an API app)

I then forwarded oof.mysite.com to foo.azurewebsites.net

This all worked nicely.

Next, I configured oof.mysite.com to use HTTPS through a certificate valid for *.mysite.com. Now, however, the communication to the API stopped working. Not too surprising perhaps, seeing how it was HTTPS to HTTP communication.

So naturally, I want to use the *.mysite.com certificate for the API too. So now I'm (well, my colleague) trying to forward rab.mysite.com to bar.azurewebsites.net but I can't see to get this IP forwarding to work in the Azure portal (the DNS propagation has already happened.)

I guess I'm asking two things:

1) Does IP forwarding to Azure API apps work differently from doing so to web apps?

2) Is there something inherently wrong in the general architecture of things?

Christofer Ohlsson
  • 111
  • 3

1 Answers1

1

You are trying to use "a certificate valid for *.mysite.com" at bar.azurewebsites.net. Of course this doesn't work! The certificate is not valid.

You need to either:

  1. load a valid separate certificate for bar.azurewebsites.net or

  2. replace the *.mysite.com with a multi-domain certificate valid for all of the mysite.com' sites _and_bar.azurewebsites.net` and load it at both domains.

Colt
  • 1,939
  • 6
  • 20
  • 25
  • But foo.mysite.com forwards to azurewebsites.net and that certificate sure works. Why would it be different on the API end? – Christofer Ohlsson Jul 02 '16 at 15:50
  • I am just responding to what you wrote: "API at `bar.azurewebsites.net`" and "I want to use the `*.mysite.com` certificate for the API too". If that is not what you meant to say, what did you mean? – Colt Jul 02 '16 at 15:53
  • 1
    I am reading your question this way: (1) user hits subdomain at `mysite.com`, which is secure; (2) `sub.mysite.com` forwards to `bar.azurewebsites.net`, which does not have its own certificate; and (3) you want to know why the connection does not stay secure under the initial `mysite.com` connection. If so, the answer is because when you "forward" traffic (vs. a reverse proxy, for example), the forwarding server (`sub.mysite.com`) issues an instruction to the client (browser) saying "hey, try this again, but use the target hostname (`bar.azurewebsites.net`), hence _new_, insecure connection. – Colt Jul 02 '16 at 16:08