"The SSL connection could not be established" when publishing despite docker login success #338
Comments
QuantumToasted
changed the title
|
@QuantumToasted I think this is because we have an assumption that any registry not explicitly on |
Not necessarily? My Portainer instance (or specifically, the registry) is intended to be local-only and not accessible outside of the LAN - my personal workflow was doing development on my desktop PC, and then However I will concede I am a total newbie when it comes to Docker and other containerization systems, as far as "best practices" go - I might just be doing something totally backwards, explaining why I am having this issue in the first place? If it would make more sense for me, a single developer, to make my workflow conform to a "standard" that most people follow, than to suggest a tool change its functionality to conform to my weird workflow, then that's fine as well. |
|
Personally, I'd like to have an option of pushing to non-localhost non-TLS registries. I appreciate that it's absolutely not good practice in any sort of professional environment but if I'm just playing around at home and want to push to a registry on a local Raspberry PI I think that should be possible without having to configure TLS, especially because I can configure Docker Desktop to allow that at my own risk. |
|
i'm experiencing the same behavior trying to publish an image to a docker engine running inside wsl2. |
|
Bump. I have a similar |
|
I am also hitting this as well, having this as an option is absolutely needed. |
|
Additionally self-signed certificates do not work just as confirmation |
|
@baronfel Any thoughts on at least implementing a way to have self-signed certs for this? |
|
@tmds you have some background here - you mentioned that it may be difficult to trust self-signed certs on Linux. do you have any docs that might clarify the situation? |
If I recall correctly, adding a self-signed cert to the system certificate store on Fedora does not cause .NET applications to trust an HTTPS server using that certificate.
Both podman and docker allow to configure certain registries as insecure. podman allows to also configure it on a per-command basis using the The SDK could pick up such a configuration setting through an environment variable, for example: |
|
same issue using k3d registry |
|
It appears that the .NET Runtime respects some OpenSSL certificate store overrides that use environment variables: dotnet/runtime#23666 (comment) Would this be acceptable here? |
|
We also host a private docker registry inside our private network without TLS. In my eyes it would be logical that the As a workaround we now forward the port on our dev-machines and (self-hosted) build agents to the registry's ip address to make use (misuse?) of the netsh interface portproxy add v4tov4 listenport=$RegistryPort listenaddress=127.0.0.1 connectaddress=$DockerRegistryIp connectport=$RegistryPort |
|
But yes - consider a new env var |
|
I just ran into this. I launched the My experience: $ docker run -d -p 5000:5000 registry
$ docker run --add-host=host.docker.internal:host-gateway --rm -it -v $(pwd):/source -w /source mcr.microsoft.com/dotnet/nightly/sdk:8.0-jammy-aot dotnet publish -p PublishProfile=DefaultContainer -p ContainerRepository=hello-native-api -p ContainerRegistry=host.docker.internal:5000
MSBuild version 17.8.3+195e7f5a3 for .NET
Determining projects to restore...
Restored /source/hello-native-api.csproj (in 3.86 sec).
/usr/share/dotnet/sdk/8.0.100-rtm.23523.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.RuntimeIdentifierInference.targets(311,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy [/source/hello-native-api.csproj]
hello-native-api -> /source/bin/Release/net8.0/linux-x64/hello-native-api.dll
hello-native-api -> /source/bin/Release/net8.0/linux-x64/publish/
Building image 'hello-native-api' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/nightly/runtime-deps:8.0-jammy-chiseled-aot'.
Uploading layer 'sha256:2cf7030f21c01c0712d16119d6d7109c7cef1e5d5c24a006f771bbfdb414a865' to 'host.docker.internal:5000'.
Uploading layer 'sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1' to 'host.docker.internal:5000'.
Uploading layer 'sha256:381ac59dfb47a15f47a006c1e4ed24b27574b8159fd282a0d53bf3491f02d4de' to 'host.docker.internal:5000'.
/usr/share/dotnet/sdk/8.0.100-rtm.23523.2/Containers/build/Microsoft.NET.Build.Containers.targets(202,5): error CONTAINER1013: Failed to push to the output registry: The SSL connection could not be established, see inner exception. [/source/hello-native-api.csproj]Same thing? |
|
Would also like the ability to publish to local docker registry without TLS. |
|
Going to close this out, as the upcoming 8.0.400 and .NET 9.0.100-preview.7 releases cover this request! |
I am attempting to publish my images to a local (LAN, not same device) registry during build via the following publish command:
However, the following error occurs during building (full build output below):
Output
Logging into this registry via
docker loginon the same machine works fine, and does not change the output whether it's run before or after the failed publish. I did have to add it as an insecure registry. (However, I don't have any local images to try pushing to see if it's an issue with the registry, sorry 😢)Is this an issue with this tool, the registry, or something else? If it perhaps could be the cause, the same local domain (
portainer.local) happens to have a self-signed cert for the portainer container itself.The text was updated successfully, but these errors were encountered: