I was given a .NET Core project to run in a Linux Docker container to do the build, everything seems to be okay on the docker configuration side, but when I run this command: dotnet publish -c Release -o out
, I get the SSL authentication error below.
The SSL connection could not be established, see inner exception. Authentication failed because the remote party has closed the transport stream.
I did my research and apparently it seemed that I was missing:
the environment variables Kestrel for ASPNET (as per https://github.com/aspnet/AspNetCore.Docs/issues/6199), which I add to my
docker-compose
, but I don’t think it is the issue.a Developer .pfx certificate, so I updated my
docker-compose
with the Kestrel Path to the certs file as seen below.
version: '3' services: netcore: container_name: test_alerting_comp tty: true stdin_open: true image: alerting_netcore environment: - http_proxy=http://someproxy:8080 - https_proxy=http://someproxy:8080 - ASPNETCORE_ENVIRONMENT=Development - ASPNETCORE_URLS=https://+;http://+ - ASPNETCORE_HTTPS_PORT=443 - ASPNETCORE_Kestrel__Certificates__Default__Password="ABC" - ASPNETCORE_Kestrel__Certificates__Default__Path=/root/.dotnet/corefx/cryptography/x509stores/my ports: - "8080:80" - "443:443" build: . #context: . security_opt: - seccomp:unconfined volumes: - "c:/FakePath/git/my_project/src:/app" - "c:/TEMP/nuget:/root" networks: - net networks: net:
I re-run the docker container and executed dotnet publish -c Release -o out
with the same results.
From my host I can do this to my local NuGet:
A) wget https://nuget.local.com/api/v2
without issues,
B) but from the container I can’t.
C) However from the container I can do this to official NuGet wget https://api.nuget.org/v3/index.json
, so definetely my proxy is working okay.
Debugging SSL issue:
The given .pfx certificate is a self-signed one, and it is working okay from Windows OS (at least I was told that).
strace
shows me from where the certs are being pulled from as below
root@9b98d5447904:/app# strace wget https://nuget.local.com/api/v2 |& grep certs open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 3
I exported the .pfx as follows:
openssl pkcs12 -in ADPRootCertificate.pfx -out my_adp_dev.crt
then moved it to/usr/local/share/ca-certificates/
, removed the private part, just left in the file public part (-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
) executedupdate-ca-certificates
and I could see1 added
, double checked in file/etc/ssl/certs/ca-certificates.crt
and the new cert was in there.Executed this again
wget https://nuget.local.com/api/v2
and failed.I used OpenSSL to get more info and as you can see it is not working, the cert has a weird CN, because they used a wildcard for the subject and to me this is wrong, but they state that .pfx is working in Windows OS.
root@ce21098e9643:/usr/local/share/ca-certificates# openssl s_client -connect nuget.local.com:443 -CApath /etc/ssl/certs CONNECTED(00000003) depth=0 CN = *.local.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = *.local.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=x00*x00lx00ox00cx00ax00lx00.x00cx00ox00m i:/C=ES/ST=SomeCity/L=SomeCity/OU=DEV/O=ASD/CN=Development CA --- Server certificate -----BEGIN CERTIFICATE----- XXXXXXXXXXX XXXXXXXXXXX -----END CERTIFICATE----- subject=s:/CN=x00*x00lx00ox00cx00ax00lx00.x00cx00ox00m issuer=i:/C=ES/ST=SomeCity/L=SomeCity/OU=DEV/O=ASD/CN=Development CA --- No client certificate CA names sent Peer signing digest: SHA1 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 1284 bytes and written 358 bytes Verification error: unable to verify the first certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: 95410000753146AAE1D313E8538972244C7B79A60DAF3AA14206417490E703F3 Session-ID-ctx: Master-Key: B09214XXXXXXX0007D126D24D306BB763673EC52XXXXXXB153D310B22C341200EF013BC991XXXXXXX888C08A954265623 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1558993408 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes ---
I don’t know what issue I’m facing, but it appears to be that:
A) the self-signed .pfx was wrongly configured, and now that it is being used in Linux it doesn’t work as it should.
B) I need some more config in the container, which I’m not aware of.
What else should I do?
I’m thinking on probaly create other cert to use from Linux hosts.
Is it feasible to create another self-signed cert with OpenSSL for IIS ver 8 and import it to IIS?.
Any ideas are welcome, cheers.
Advertisement
Answer
ANSWERING TO MYSELF
It was not a Linux container issue, it is a certificate issue in the web server (IIS), because we are using self-signed certificates and in this way the cert will be always an invalid certificate
. Self-signed certs works okay on Windows OS side, doesn’t matter the invalid error. Of course self-signed certs are just for a test environment or so.
From Linux OS when you are trying to pull packages from NuGet you will get the error below, because:
1) The cert is indeed invalid, and
2) because apparently there is not an option to ignore an invalid certificate from Linux side.
The SSL connection could not be established, see inner exception. The remote certificate is invalid according to the validation procedure.
The solution is you are working in a corporate environment, is to request to System Administrator a proper signed certificate, for that you generate a CSR from your web server, in my case IIS, then pass it to them, so they will send you back a .cer file to install in that web server.
The other option that I was trying to do but I couldn’t due to the limitations of my corporate environment, is to create a fake CA (with OpenSSL), then you sign the CSR’s yourself to have some valid certificates for your Dev or test environment.
Apologizes for answering this myself, but I believe it is worth to share my findings.
Hope it helps.