我获得了一个.NET Core项目,该项目可以在Linux Docker容器中运行以进行构建,在Docker配置方面一切正常,但是当我运行以下命令:dotnet publish -c Release -o out时,出现以下SSL身份验证错误。The SSL connection could not be established, see inner exception. Authentication failed because the remote party has closed the transport stream.我做了研究,显然我似乎不见了:

  • 用于ASPNET的环境变量Kestrel(根据https://github.com/aspnet/AspNetCore.Docs/issues/6199),我将其添加到docker-compose中,但我认为这不是问题。
  • 是开发人员.pfx证书,因此我使用Kestrel路径的certs文件更新了docker-compose,如下所示。
  • 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:
    
    我重新运行docker容器并执行dotnet publish -c Release -o out,结果相同。
    在我的主机上,我可以对本地NuGet执行此操作:
    A)wget https://nuget.local.com/api/v2没有问题,
    B)但不能从容器中取出。
    C)但是从容器中,我可以对NuGet官方wget https://api.nuget.org/v3/index.json进行此操作,因此我的代理肯定可以正常工作。
    调试SSL问题:
    给定的.pfx证书是自签名证书,可以从Windows OS正常工作(至少有人告诉我)。
  • strace向我显示了从何处提取证书,如下所示
  • root@9b98d5447904:/app# strace wget https://nuget.local.com/api/v2 |& grep certs open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 3
  • 我将.pfx导出如下:openssl pkcs12 -in ADPRootCertificate.pfx -out my_adp_dev.crt然后将其移至/usr/local/share/ca-certificates/,除去私有(private)部分,在文件公共(public)部分(-----BEGIN CERTIFICATE----- -----END CERTIFICATE----- )左端执行update-ca-certificates,我可以看到1 added,再次检查了文件/etc/ssl/certs/ca-certificates.crt,并且新证书在那里。
  • 再次执行此wget https://nuget.local.com/api/v2并失败。
  • 我使用OpenSSL来获取更多信息,并且您可以看到它不起作用,该证书具有怪异的CN,因为他们使用了通配符作为主题,这对我来说是错误的,但是他们指出.pfx在Windows中可以正常工作操作系统。
  • 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
    ---
    
    我不知道我要面对什么问题,但这似乎是:
    A)自签名的.pfx配置错误,现在在Linux中使用它,因此无法正常工作。
    B)我需要在容器中进行一些其他配置,但我不知道。
    我还应该怎么办?
    我正在考虑从Linux主机上创建其他证书以供使用。
    是否可以使用适用于IIS ver 8的OpenSSL创建另一个自签名证书并将其导入IIS?
    任何想法都欢迎,欢呼。

    最佳答案

    回答自己

    这不是Linux容器问题,而是,它是Web服务器(IIS)中的证书问题,因为我们使用的是自签名证书,因此该证书将始终是invalid certificate 。自签名证书可以在Windows操作系统上正常运行,与无效错误无关。当然,自签名证书仅适用于测试环境。

    当您尝试从NuGet中提取软件包时,从Linux OS中会出现以下错误,因为:

    1)证书确实无效,并且

    2)因为显然没有选择忽略来自Linux端的无效证书。

    The SSL connection could not be established, see inner exception.
    The remote certificate is invalid according to the validation procedure.
    

    解决方案是您在公司环境中工作,是向系统管理员请求正确的签名证书,因为您需要从Web服务器(在我的情况下为IIS)中生成CSR,然后将其传递给他们,以便他们发送您备份一个.cer文件以安装在该Web服务器中。

    我试图做但由于公司环境的限制而无法执行的另一种方法是创建一个伪造的CA(使用OpenSSL),然后您自己对CSR进行签名以为您的开发人员提供一些有效的证书或测试环境。

    对我自己回答这个问题表示歉意,但我认为值得分享我的发现。

    希望能帮助到你。

    关于linux - 由于对Nuget进行SSL身份验证,因此在docker linux容器中构建.NET Core失败,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/56347153/

    10-16 21:40