.NET Core build in docker linux container fails due to SSL authentication to Nuget

Question

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:

1. 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.

2. 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).

1. 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

2. 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----- ) executed update-ca-certificates and I could see 1 added, double checked in file /etc/ssl/certs/ca-certificates.crt and the new cert was in there.

3. Executed this again wget https://nuget.local.com/api/v2 and failed.

4. 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*\x00l\x00o\x00c\x00a\x00l\x00.\x00c\x00o\x00m
   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*\x00l\x00o\x00c\x00a\x00l\x00.\x00c\x00o\x00m
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.

Answer 1

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.