SSL Traffic Using a WebProxy from a Docker Container - docker

I am trying to setup my container to send some of its outgoing traffic to Fiddler (for debugging my application).
I setup it up like this:
services.AddHttpClient("OAuthClient").ConfigurePrimaryHttpMessageHandler(x =>
{
var handler = new HttpClientHandler
{
Proxy = new WebProxy("http://host.docker.internal:8888"),
UseProxy = true
};
return handler;
});
And this works fine when I run normal HTTP traffic from the container. It also works fine when I run HTTPS traffic from my dev machine. When when I try to run HTTPS traffic from a container, I get the following error:
The SSL connection could not be established, see inner exception.
And the inner exception is:
System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
I looked that up and from what I can see it is a "Self Signed Certificate" issue. But I am not sure where it thinks it is is finding the self signed certificate. Is it the container, the host or the url I am trying to call?
I feel that a container using a fiddler proxy is common enough that this should be a solved problem.
How can I pass my container's HTTPS traffic to fiddler?

Related

github webhook fails to connect to jenkins with public ip

I am trying to configure github webhooks with my jenkins server but I keep getting "failed to connect". Note that I am using a public ip and not a private or localhost address, At first, icmp protocol was blocked on my firewall but even after allowing it, it still doesn't work.
However, when I proxy my server (using smee client) and use the proxied url in the webhook instead, it works fine, so I thought the problem was jenkins url (in system configuration of jenkins) so I changed that to the public ip but it doesn't have any effect, now I'm clueless.
It might be relevant to mention that jenkins is running on a docker container,
Apparently the webhook must pass through a web server and not to jenkins directly, So I configured nginx as a reverse proxy to jenkins server and it worked fine.

Asp.net APIs have wrong certificate, Blazor website refuses to connect

I have the following setup: One Blazor Server Side Website, an ASP.net API Gateway using Ocelot and a few Microservices also using ASP.net. All of these things are run in individual Docker Containers.
First of, everything works, the connections work, I can fetch data, but only on http. I have the dev-certs enabled for ASP.net, and they also "work" but the problem is, they are signed for the wrong host.
When I navigate to a gateway with the browser, it works as long as I call "localhost" and the port. The problem is, because they run in Containers, localhost does not mean the same thing for them. That means I have to use my local IP and the port to send them to the correct service. But the certificate is signed for "localhost" meaning it thinks the cert is invalid because the host is no longer "localhost".
This means that my blazor app sees a certificate that does not match the host and gets an exception because it can't validate the cert. I looked up a lot of stuff and found nothing, but basically I need a way to either change the certificates in the containers or tell the blazor server to accept those certificates.
I have not found a thing on this topic, so I would really appreciate some help.

Docker and EF Core: No connection could be made because the target machine actively refused it

I try to connect to the host's SQL Server Instance (SQL 2017 on Windows 10) from a Docker container (running a .NET Core app with EF Core).
The SQL Server is configured to listen on the default port 1433 (no dynamic ports are used) and to allow remote connections (TCP/IP). I also set up an inbound rule for the firewall and the given port (I also tried with firewall off). I can connect to the database and run SQL queries with the sqlcmd command line tool running in a Docker container.
This is the connection string I'm using:
Server=tcp:host.docker.internal,1433;Database=AuthIdentity;Trusted_Connection=False;User Id=sa;Password=xxxx;MultipleActiveResultSets=True;
When I run my container I get the following error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: TCP
Provider, error: 0 - No connection could be made because the target
machine actively refused it.)
When I turn off my firewall (even if there is a firewall rule for the SQL port) I'll end up getting:
SqlException: A network-related or instance-specific error occurred
while establishing a connection to SQL Server. The server was not
found or was not accessible. Verify that the instance name is correct
and that SQL Server is configured to allow remote connections.
(provider: TCP Provider, error: 0 - A connection attempt failed
because the connected party did not properly respond after a period of
time, or established connection failed because connected host has
failed to respond.)
When I start the same program as IIS application (without any other changes) it's running perfectly fine and it's connecting as expected.
The error occurs when the program executes the first SQL operations (in this case it's the database migration - this is within the program startup)
serviceScope.ServiceProvider.GetRequiredService<ApplicationDbContext>().Database.Migrate();
EDIT: A simpler setup in another API project (both will raise the same errors as described above):
[HttpGet("setup")]
[AllowAnonymous]
public IActionResult Setup()
{
try
{
this._context.Database.Migrate();
return Ok("success");
}
catch (Exception e)
{
return Json(e);
}
}
[HttpGet("get")]
[AllowAnonymous]
public List<ApplicationUser> Get()
{
return this._context.Users.ToList();
}
EDIT 2: As suggested from #Mohsin Mehmood I run a test with the NAT address (from ipconfig /all) and I can successfully connect with the given IP (172.28.112.1) to the SQL server. I also checked what I receive when running docker run --rm -i microsoft/nanoserver:1709 ping host.docker.internal and it gets me 62.138.239.45 as the address.
Never the less I would appreciate a solution which is not using a "hard-coded" IP address but a DNS like host.docker.internal. I'm also not sure why both IP addresses are different (172.28.112.1 vs. 62.138.239.45) and why the container can't get the correct address from the DNS.
What are the things I'm missing? How can this problem be solved? I already searched Google and SO without any working answer.
I suggest to try Windows 10 host server IP address instead of domain host.docker.internal to confirm that issue is related to DNS resolution. Also, I found that there is still an open issue related to internal host dns resolution in windows containers

How can I talk https to my local docker registry (sonatype nexus)

From the documentation found here: https://books.sonatype.com/nexus-book/3.0/reference/docker.html
I can conclude that I cannot create a private docker registry unless I expose it through https.
Docker relies on secure connections using SSL to connect to the repositories. You are therefore required to expose the repository manager to your client tools via HTTPS. This can be configured via an external proxy server or directly with the repository manager. Further details can be found in Section 5.9.4, “Inbound SSL - Configuring to Serve Content via HTTPS”.
I have done all these steps (using reverse-proxy on https://localhost:5001 forwarding to nexus proxy registry with http connector). However now that I want to start pulling from my local registry, I cannot find a way to access it through https.
The following command which is describe here: https://docs.docker.com/engine/reference/commandline/pull/#pull-from-a-different-registry
docker pull localhost:5001/hello-world
returns:
Error response from daemon: error parsing HTTP 400 response body: invalid character '<' looking for beginning of value: "\n\n400 Bad Request\n\nBad Request\nYour browser sent a request that this server could not understand.\nReason: You're speaking plain HTTP to an SSL-enabled server port.\n Instead use the HTTPS scheme to access this URL, please.\n\n\n"
and when I try this:
docker pull https://localhost:5001/hello-world
I get:
invalid reference format
The solution to this is:
either having a valid SSL certificate for the proxy you re accessing the repository through
or
creating a self-signed certificate and manually inserting it in the Windows Trusted root authorities certificates
of the computer you want to access the registry from.
This should resolve any issues and relevant messages. Try accessing https://proxyUrl:5000/v2 and you should now be getting a different message than before as well as be able to pull and push to the registry.

Jenkins Server - Issues with setting URL

I am trying to set up an internal Jenkins server for our QA team and facing some issues with the server URL. This is inside a corporate network and all sort of firewall and proxy settings are in place, however we need to access the server only with in our internal network. This server runs from a Mac Mini. I was able to install and access the server without any issues using localhost:8080.
I tried to set a custom URL (something like testjenkins.local:8080)under the Manage Jenkins option and never was able to access the server. The only option worked for me is with the IP address (IP:8080). I was able to access the server from other machines in the network using this URL.
The real problem with the above setup is that the machine IP changes(I am not able to make it static), and hence wont be able to get an always working URL.
Highly appreciate if any one guide me in the wright direction.
Given you have a dynamic IP on your server, a good alternative would be using ngrok. Ngrok can expose the port 8080 of that server to the internet via secure tunnels, and you can access it via an URL, so changes in the IP won't affect it.
However, ngrok exposes the server to the whole Internet. To make it accessible only for your team you can add authentication in both ngrok tunnel and Jenkins server (would it work for you?).

Resources