<div dir="ltr">Sorry Alex but if using postman I just post to the internal URL with no certificates and everything works fine. All I'm trying to do is post to the squid server that will then redirect the post to the external url.  Its that simple .. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 25, 2021 at 11:55 AM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/25/21 5:23 AM, Mike Yates wrote:<br>
> There are no certificates to worry about, the api is expecting a token<br>
> to be included in the payload of the call.   So all squid needs to do is<br>
> accept the post from the internal server and pass that post to the<br>
> external servers url including the payload.  <br>
<br>
> I hope that helps.  <br>
<br>
Not yet. Forget about payload for a second. Our problems are still at a<br>
much higher level: In your examples, you used https://... URLs. Do<br>
internal servers make HTTPS requests (i.e. HTTP requests over SSL/TLS<br>
connections)? If yes, then why are you saying that there are no<br>
certificates to worry about? TLS connections normally involve<br>
certificate validation!..<br>
<br>
Perhaps those internal servers make plain HTTP requests, and you used<br>
"https://..." URLs in your examples by accident?<br>
<br>
BTW, if you do not know the answers to some of the questions, please<br>
just say so -- there is nothing wrong with that. If you can share a<br>
small packet capture of a single request/response (in libpcap format),<br>
that may reduce the number of questions we have to ask.<br>
<br>
Alex.<br>
<br>
<br>
> On Fri, Sep 24, 2021, 18:01 Alex Rousskov wrote:<br>
> <br>
>     On 9/24/21 5:26 PM, Mike Yates wrote:<br>
>     > Ok so let's say the new server outside the dmz has a different name. I<br>
>     > need a squid server configuration that will just forward the api calls<br>
>     > to an external address.  So my internal servers will still point<br>
>     to Fred<br>
>     > ( which is now a squid server and has access to the outside world) and<br>
>     > will then forward the requests to the new server I have in the cloud. <br>
>     > Long story short I just need a pass through squid server.   <br>
> <br>
>     Will those internal servers trust the certificate you configure Squid<br>
>     with? In your example, you used "https://...". That usually means the<br>
>     internal servers are going to validate the server certificate. Can you<br>
>     make them trust the Squid certificate? Or does the API communication<br>
>     have to be signed by a <a href="http://fred.mydomain.com" rel="noreferrer" target="_blank">fred.mydomain.com</a> <<a href="http://fred.mydomain.com" rel="noreferrer" target="_blank">http://fred.mydomain.com</a>><br>
>     certificate that you do not<br>
>     control?<br>
> <br>
>     The other pending question is whether those internal servers are<br>
>     configured to use a proxy (see the previous email on this thread) or<br>
>     always talk directly to (what they think is) the API service?<br>
> <br>
>     Alex.<br>
> <br>
> <br>
>     > On Fri, Sep 24, 2021, 17:18 Alex Rousskov wrote:<br>
>     ><br>
>     >     On 9/24/21 5:09 PM, Mike Yates wrote:<br>
>     >     > I have a bunch of internal machines that do not have internet<br>
>     >     access and<br>
>     >     > any one of them is sending api post requests to another<br>
>     system on prem<br>
>     >     > and having no issues ….<br>
>     >     ><br>
>     >     >  <br>
>     >     ><br>
>     >     > Example would be <a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a><br>
>     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a>><br>
>     >     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a><br>
>     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a>>><br>
>     >     ><br>
>     >     >  <br>
>     >     ><br>
>     >     > Now the problem becomes the fred server is being moved to<br>
>     the cloud so<br>
>     >     > the same <a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a><br>
>     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a>><br>
>     >     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a><br>
>     <<a href="https://fred.mydomain.com/api/event" rel="noreferrer" target="_blank">https://fred.mydomain.com/api/event</a>>> is still valid but none of my<br>
>     >     > internal server can see fred and I don’t have access to the<br>
>     backend<br>
>     >     > servers to change their api calls.<br>
>     ><br>
>     >     AFAICT from your summary, "moved to cloud" here means that the API<br>
>     >     protocol stays the same, the API server domain name stays the<br>
>     same, the<br>
>     >     API URL path stays the same, but the IP address of that domain<br>
>     name will<br>
>     >     change. Please clarify if that conclusion is wrong.<br>
>     ><br>
>     >     If it is correct, then it is not clear how the change of an IP<br>
>     address<br>
>     >     would affect those making API requests using the domain name,<br>
>     and what<br>
>     >     role Squid is playing here.<br>
>     ><br>
>     >     Alex.<br>
>     ><br>
> <br>
<br>
</blockquote></div>