运行启用了TLS的中间CA:拒绝与根CA的连接 [英] Run intermediate CA with TLS enabled: connection to root CA refused

查看：125
本文介绍了运行启用了TLS的中间CA:拒绝与根CA的连接的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

因此，我正在尝试创建一个具有根CA和几个中间CA(每个组织一个)的结构网络，每个CA均启用TLS和自签名证书(无密码).运行根CA之后，我为其注册管理员，并使用标志hf.IntermediateCA=true创建中间CA的从属关系并注册身份.然后，我将tls-cert.pem从根CA复制到中间CA要使用的卷，然后尝试开始发布中间CA:

So, I am trying to create a fabric network with a root CA, and several intermediate CAs, one for each org, everything with TLS enabled and self signed certs (no cryptogen). After running the root CA, I enroll the admin for it, and create affiliations and register identities for the intermediate CAs using the flag hf.IntermediateCA=true. Then I copy the tls-cert.pem from the root CA to the volume to be used by the intermediate CA, and then I try to start the intermediate CA issuing:

fabric-ca-server start -b admin:adminpw -u https://<registered-identity>:<pw>@ca-root:7054 --tls.certfile /path/to/copied/tls-cert.pem

然后我得到以下答案:

[lots of things...]
Post https://ca-root:7054/enroll: dial tcp 10.111.83.239:7054: connect: connection refused

没有任何有关为何拒绝连接的线索.检查根CA的日志似乎没有任何反应.我也知道这不是连通性问题(我在minikube上，从日志中可以看出，DNS已正确解析-再次检查).我尝试使用env变量而不是CLI标志，还尝试使用具有相同证书的标志--intermediate.tls.certfiles，还尝试了ca-root-cert.pem而不是tls-cert.pem(我认为这也可以工作) )，所有结果都相同.

Without any clue about why the connection was refused. Checking the logs of the root CA looks like if nothing happened. Also I know it is not a connectivity problem (I'm on minikube and as can be seen in the logs, the DNS is being resolved correctly - double checked). I tried using env variables instead of the CLI flag, also tried using the flag --intermediate.tls.certfiles with the same certificate, and also tried the ca-root-cert.pem instead of the tls-cert.pem (which I think should also work), all with the same result.

重要的是，如果我在各处禁用TLS，我就能够毫无问题地启动中间CA，但是我确实需要启用它.

Important to say that I've been able to start intermediate CAs without problem if I disable TLS everywhere, but I really need to enable this.

我正在使用结构1.4.2图像.

I am using fabric 1.4.2 images.

我想念什么?谢谢！

:要回答@kekomal问题:我对TLS证书和启用调试模式都使用了两个标志.这是完整的中级CA日志:

To answer @kekomal questions: I used both flags for TLS cert and enebled debug mode. Here's the complete Intermediate CA's log:

2019/10/25 08:22:56 [DEBUG] Home directory: /etc/hyperledger/fabric-ca-server
2019/10/25 08:22:56 [INFO] Configuration file location: /etc/hyperledger/fabric-ca-server/fabric-ca-server-config.yaml
2019/10/25 08:22:56 [INFO] Starting server in home directory: /etc/hyperledger/fabric-ca-server
2019/10/25 08:22:56 [DEBUG] Set log level:
2019/10/25 08:22:56 [INFO] Server Version: 1.4.2
2019/10/25 08:22:56 [INFO] Server Levels: &{Identity:2 Affiliation:1 Certificate:1 Credential:1 RAInfo:1 Nonce:1}
2019/10/25 08:22:56 [DEBUG] Making server filenames absolute
2019/10/25 08:22:56 [DEBUG] Initializing default CA in directory /etc/hyperledger/fabric-ca-server
2019/10/25 08:22:56 [DEBUG] Init CA with home /etc/hyperledger/fabric-ca-server and config {Version:1.4.2 Cfg:{Identities:{PasswordAttempts:10 AllowRemove:false} Affiliations:{AllowRemove:false}} CA:{Name:ca-corp Keyfile: Certfile:ca-cert.pem Chainfile:ca-chain.pem} Signing:0xc000220870 CSR:{CN: Names:[{C:US ST:North Carolina L: O:Hyperledger OU:Fabric SerialNumber:}] Hosts:[0.0.0.0 ca-corp ca-corp.blockchain-alm-ns.svc localhost] KeyRequest:0xc00022cfe0 CA:0xc00022d060 SerialNumber:} Registry:{MaxEnrollments:-1 Identities:[{ Name:**** Pass:**** Type:client Affiliation: MaxEnrollments:0 Attrs:map[hf.Registrar.Roles:* hf.Registrar.DelegateRoles:* hf.Revoker:1 hf.IntermediateCA:1 hf.GenCRL:1 hf.Registrar.Attributes:* hf.AffiliationMgr:1]  }]} Affiliations:map[org1:[department1 department2] org2:[department1]] LDAP:{ Enabled:false URL:ldap://****:****@<host>:<port>/<base> UserFilter:(uid=%s) GroupFilter:(memberUid=%s) Attribute:{[uid member] [{ }] map[groups:[{ }]]} TLS:{false [] { }}  } DB:{ Type:sqlite3 Datasource:fabric-ca-server.db TLS:{false [] { }}  } CSP:0xc00022d100 Client:<nil> Intermediate:{ParentServer:{ URL:https://****:****@ca-root:7054 CAName:  } TLS:{Enabled:false CertFiles:[/etc/hyperledger/fabric-ca-server/tls-cert.pem] Client:{KeyFile: CertFile:}} Enrollment:{ Name: Secret:**** CAName: AttrReqs:[] Profile: Label: CSR:<nil> Type:x509  }} CRL:{Expiry:24h0m0s} Idemix:{IssuerPublicKeyfile: IssuerSecretKeyfile: RevocationPublicKeyfile: RevocationPrivateKeyfile: RHPoolSize:1000 NonceExpiration:15s NonceSweepInterval:15m}}
2019/10/25 08:22:56 [DEBUG] CA Home Directory: /etc/hyperledger/fabric-ca-server
2019/10/25 08:22:56 [DEBUG] Checking configuration file version '1.4.2' against server version: '1.4.2'
2019/10/25 08:22:56 [DEBUG] Initializing BCCSP: &{ProviderName:SW SwOpts:0xc0001d0500 PluginOpts:<nil>}
2019/10/25 08:22:56 [DEBUG] Initializing BCCSP with software options &{SecLevel:256 HashFamily:SHA2 Ephemeral:false FileKeystore:0xc00022f4b0 DummyKeystore:<nil> InmemKeystore:<nil>}
2019/10/25 08:22:56 [DEBUG] Initialize key material
2019/10/25 08:22:56 [DEBUG] Making CA filenames absolute
2019/10/25 08:22:56 [WARNING] &{69 The specified CA certificate file /etc/hyperledger/fabric-ca-server/ca-cert.pem does not exist}
2019/10/25 08:22:56 [DEBUG] Getting CA cert; parent server URL is https://****:****@ca-root:7054
2019/10/25 08:22:56 [DEBUG] Intermediate enrollment request: { Name: Secret:**** CAName: AttrReqs:[] Profile:ca Label: CSR:&{ [] [] <nil> 0xc00022d5a0 } Type:x509  }, CSR: &{CN: Names:[] Hosts:[] KeyRequest:<nil> CA:0xc00022d5a0 SerialNumber:}, CA: &{PathLength:0 PathLenZero:true Expiry:}
2019/10/25 08:22:56 [DEBUG] Enrolling { Name:ca-corp Secret:**** CAName: AttrReqs:[] Profile:ca Label: CSR:&{ [{US North Carolina  Hyperledger Fabric }] [0.0.0.0 ca-corp ca-corp.blockchain-alm-ns.svc localhost] 0xc00022cfe0 0xc00022d060 } Type:x509  }
2019/10/25 08:22:56 [DEBUG] Initializing client with config: &{URL:https://ca-root:7054 MSPDir: TLS:{Enabled:true CertFiles:[/etc/hyperledger/fabric-ca-server/tls-cert.pem] Client:{KeyFile: CertFile:}} Enrollment:{ Name:ca-corp Secret:**** CAName: AttrReqs:[] Profile:ca Label: CSR:&{ [{US North Carolina  Hyperledger Fabric }] [0.0.0.0 ca-corp ca-corp.blockchain-alm-ns.svc localhost] 0xc00022cfe0 0xc00022d060 } Type:x509  } CSR:{CN: Names:[{C:US ST:North Carolina L: O:Hyperledger OU:Fabric SerialNumber:}] Hosts:[0.0.0.0 ca-corp ca-corp.blockchain-alm-ns.svc localhost] KeyRequest:0xc00022cfe0 CA:0xc00022d060 SerialNumber:} ID:{Name: Type: Secret: MaxEnrollments:0 Affiliation: Attributes:[] CAName:} Revoke:{Name: Serial: AKI: Reason: CAName: GenCRL:false} CAInfo:{CAName:} CAName: CSP:0xc00022d100 Debug:false LogLevel:}
2019/10/25 08:22:56 [DEBUG] Initializing BCCSP: &{ProviderName:SW SwOpts:0xc0001d0500 PluginOpts:<nil>}
2019/10/25 08:22:56 [DEBUG] Initializing BCCSP with software options &{SecLevel:256 HashFamily:SHA2 Ephemeral:false FileKeystore:0xc00022f4b0 DummyKeystore:<nil> InmemKeystore:<nil>}
2019/10/25 08:22:56 [INFO] TLS Enabled
2019/10/25 08:22:56 [DEBUG] CA Files: [/etc/hyperledger/fabric-ca-server/tls-cert.pem]
2019/10/25 08:22:56 [DEBUG] Client Cert File:
2019/10/25 08:22:56 [DEBUG] Client Key File:
2019/10/25 08:22:56 [DEBUG] Client TLS certificate and/or key file not provided
2019/10/25 08:22:56 [DEBUG] GenCSR &{CN: Names:[{C:US ST:North Carolina L: O:Hyperledger OU:Fabric SerialNumber:}] Hosts:[0.0.0.0 ca-corp ca-corp.blockchain-alm-ns.svc localhost] KeyRequest:0xc00022cfe0 CA:0xc00022d060 SerialNumber:}
2019/10/25 08:22:56 [INFO] generating key: &{A:ecdsa S:256}
2019/10/25 08:22:56 [DEBUG] generate key from request: algo=ecdsa, size=256
2019/10/25 08:22:56 [INFO] encoded CSR
2019/10/25 08:22:56 [DEBUG] Sending request
POST https://ca-root:7054/enroll
{"hosts":["0.0.0.0","ca-corp","ca-corp.blockchain-alm-ns.svc","localhost"],"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBgzCCASoCAQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9s\naW5hMRQwEgYDVQQKEwtIeXBlcmxlZGdlcjEPMA0GA1UECxMGRmFicmljMRAwDgYD\nVQQDEwdjYS1jb3JwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEws3abjcupN/X\nVa53vjv9Cdv1oVT/fDF4wNLGrNs6gMazFKN+0FCBQIywQxbdqszAxwl0Wh1yYzm5\np4E17FPPnqBpMGcGCSqGSIb3DQEJDjFaMFgwQgYDVR0RBDswOYIHY2EtY29ycIId\nY2EtY29ycC5ibG9ja2NoYWluLWFsbS1ucy5zdmOCCWxvY2FsaG9zdIcEAAAAADAS\nBgNVHRMBAf8ECDAGAQH/AgEAMAoGCCqGSM49BAMCA0cAMEQCIHvXuMelMU9gVgWu\nb0tURDxJ/W5yvwikVEiMjAFma9tpAiBl3YQ1pbcNH53QAhn/4TjLaQLKeVDrK4a9\nX3/4HvG8iw==\n-----END CERTIFICATE REQUEST-----\n","profile":"ca","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","CAName":""}
2019/10/25 08:22:57 [DEBUG] Closing server DBs
Error: POST failure of request: POST https://ca-root:7054/enroll
{"hosts":["0.0.0.0","ca-corp","ca-corp.blockchain-alm-ns.svc","localhost"],"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBgzCCASoCAQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9s\naW5hMRQwEgYDVQQKEwtIeXBlcmxlZGdlcjEPMA0GA1UECxMGRmFicmljMRAwDgYD\nVQQDEwdjYS1jb3JwMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEws3abjcupN/X\nVa53vjv9Cdv1oVT/fDF4wNLGrNs6gMazFKN+0FCBQIywQxbdqszAxwl0Wh1yYzm5\np4E17FPPnqBpMGcGCSqGSIb3DQEJDjFaMFgwQgYDVR0RBDswOYIHY2EtY29ycIId\nY2EtY29ycC5ibG9ja2NoYWluLWFsbS1ucy5zdmOCCWxvY2FsaG9zdIcEAAAAADAS\nBgNVHRMBAf8ECDAGAQH/AgEAMAoGCCqGSM49BAMCA0cAMEQCIHvXuMelMU9gVgWu\nb0tURDxJ/W5yvwikVEiMjAFma9tpAiBl3YQ1pbcNH53QAhn/4TjLaQLKeVDrK4a9\nX3/4HvG8iw==\n-----END CERTIFICATE REQUEST-----\n","profile":"ca","crl_override":"","label":"","NotBefore":"0001-01-01T00:00:00Z","NotAfter":"0001-01-01T00:00:00Z","CAName":""}: Post https://ca-root:7054/enroll: dial tcp 10.110.28.98:7054: connect: connection refused

以及来自CA根目录的日志:

And the logs from the CA root:

2019/10/25 08:18:21 [DEBUG] DB: Getting identity admin
2019/10/25 08:18:21 [DEBUG] Successful token authentication of 'admin'
2019/10/25 08:18:21 [DEBUG] Received registration request from admin: { Name:ca-corp Type:client Secret:**** MaxEnrollments:0 Affiliation: Attributes:[{hf.IntermediateCA true false}] CAName:  }
2019/10/25 08:18:21 [DEBUG] No affiliation provided in registration request, will default to using registrar's affiliation of ''
2019/10/25 08:18:21 [DEBUG] canRegister - Check to see if user 'admin' can register
2019/10/25 08:18:21 [DEBUG] Checking to see if caller 'admin' can act on type 'client'
2019/10/25 08:18:21 [DEBUG] Checking to see if caller 'admin' is a registrar
2019/10/25 08:18:21 [DEBUG] Validating affiliation:
2019/10/25 08:18:21 [DEBUG] Checking to see if affiliation '' contains caller's affiliation ''
2019/10/25 08:18:21 [DEBUG] Caller has root affiliation
2019/10/25 08:18:21 [DEBUG] Checking to see if registrar can register the requested attributes: [{Name:hf.IntermediateCA Value:true ECert:false}]
2019/10/25 08:18:21 [DEBUG] Validating that registrar with the following values for hf.Registrar.Attributes '*' is authorized to register the requested attribute '&{Name:hf.IntermediateCA Value:true ECert:false}'
2019/10/25 08:18:21 [DEBUG] Checking if registrar can register attribute: hf.IntermediateCA
2019/10/25 08:18:21 [DEBUG] Performing authorization check...
2019/10/25 08:18:21 [DEBUG] Checking if caller is authorized to register attribute 'hf.IntermediateCA' with the requested value of 'true'
2019/10/25 08:18:21 [DEBUG] Requested attribute type is boolean
2019/10/25 08:18:21 [DEBUG] Registering user id: ca-corp
2019/10/25 08:18:21 [DEBUG] Max enrollment value verification - User specified max enrollment: 0, CA max enrollment: -1
2019/10/25 08:18:21 [DEBUG] DB: Getting identity ca-corp
2019/10/25 08:18:21 [DEBUG] DB: Add identity ca-corp
2019/10/25 08:18:21 [DEBUG] Successfully added identity ca-corp to the database
2019/10/25 08:18:21 [INFO] 127.0.0.1:34862 POST /register 201 0 "OK"
2019/10/25 08:30:30 [DEBUG] Cleaning up expired nonces for CA 'ca-root'

在这里您可以看到在启动中间CA时先前应该注册的身份注册过程.但是没有显示任何注册过程(拒绝连接).

Where you can see the previous process of registering the identity that should be enrolled when starting the intermediate CA. But does not show anything for the enrolling process (the refused connection).

关于您的评论:您说我也应该在启动中间CA时发送--tls.keyfile.我不明白...私钥应始终由所有者(在本例中为根CA)保留，我是否还应将其复制到中间CA的卷中?为什么?有意义吗?

Regarding your comment: you say that I should also send --tls.keyfile while starting intermediate CA. I don't understand this... private key should always be kept by the owner (in this case the root CA), should I also copy it to intermediate CA's volume? why? does that make any sense?

最后，@ kekomal的回答为我提供了线索:添加有关父CA的CN的信息使我走得更远.工作命令是:

Edit 2: Finally @kekomal's answer gave me the clue: adding information about the CN of the parent CA let me go further. The working command is:

fabric-ca-server start -b admin:adminpw -u https://<registered-identity>:<pw>@ca-root:7054 --intermediate.parentserver.caname ca-root --tls.certfile /path/to/copied/tls-cert.pem

新部分为--intermediate.parentserver.caname ca-root.但是...发出此命令在中间CA的日志中给了我一个新错误:

Where the new part is --intermediate.parentserver.caname ca-root. BUT... Issuing this command gave me a new error in the intermediate CA's log:

Error: Could not load TLS certificate with BCCSP: Could not find matching private key for SKI: Failed getting key for SKI [[167 199 194 85 105 166 191 99 62 19 149 57 140 61 6 182 134 104 105 223 132 142 13 221 99 68 170 0 45 246 28 17]]: Key with SKI a7c7c25569a6bf633e1395398c3d06b6866869df848e0ddd6344aa002df61c11 not found in /etc/hyperledger/fabric-ca-server/msp/keystore

按照错误提示，我将私钥从根CA复制到/etc/hyperledger/fabric-ca-server/msp/keystore中的中间CA，然后，中间CA终于启动了.

As the error suggested, I copied the private key from the root CA to the intermediate CA inside /etc/hyperledger/fabric-ca-server/msp/keystore, and just after that, the intermediate CA finally started.

但是为什么有必要将此PK从根复制到中间CA?当我们使用非对称密码技术时，我真的很困惑.是虫子吗?还是我缺少重要的东西?

But why is it necessary to copy this PK from root to intermediate CA? I'm really confused as we are working with asymmetric cryptography. Is it a bug? or am I missing something important?

好的，对此进行了另一项更新:正如@kekomal所建议的那样，我尝试在不启用中间CA中启用tls的情况下发出命令.因此，我停止了网络，删除了中间CA的持久性，并按建议发出了命令.令我惊讶的是，结果再次是connection refused消息.然后我再次尝试了fabric-ca-server start的所有变体，但是没有运气(相同的连接被拒绝的消息).最终，我意识到它最后一次起作用了，我首先发布了一个不带参数的fabric-ca-server启动(将其作为独立服务器启动)，停止了它，然后发送了带参数的命令.因此，这次我要做的是先发送fabric-ca-server init -b admin:adminpw，然后发送fabric-ca-server start -b admin:adminpw -u https://ca-corp:NdckmlUAhTUP@ca-root:7054 --tls.enabled --intermediate.parentserver.caname ca-root --intermediate.tls.certfiles /etc/hyperledger/fabric-ca-server/tls-cert.pem(是的，启用--tls.，因为我希望整个CA网络都启用tls，而不仅仅是根CA)，是的，中间CA现在正在运行，是的，不需要复制根CA的PK.我的结论是，即使结构文档指出在不运行init的情况下开始运行之前也会隐式运行init，但那里的某些功能仍然无法正常工作，并且必须在启动前调用 init 才能正常运行，至少在启用了TLS.

Edit 3: Ok, one more update on this: As suggested by @kekomal, I tried issuing the command without enabling tls in the intermediate CA. So I stopped the network, deleted persistence for intermediate CA, and issued the command as suggested. To my surprise, the result was again a connection refused message. Then I tried again all the variations of fabric-ca-server start with no luck (same connection refused message). Finally I realized that the last time it worked, I issued first a fabric-ca-server start without params (to start it as a stand alone server), stopped it, and then sent the command with params. So, what I have done this time is to send first a fabric-ca-server init -b admin:adminpw, and then send the fabric-ca-server start -b admin:adminpw -u https://ca-corp:NdckmlUAhTUP@ca-root:7054 --tls.enabled --intermediate.parentserver.caname ca-root --intermediate.tls.certfiles /etc/hyperledger/fabric-ca-server/tls-cert.pem (yes, with --tls.enabled, because I want the entire CAs network to work with tls enabled, not just the root CA), and yes!, intermediate CA is now working, and yes!, there was no need to copy the root CA's PK. My conclussion is that even when fabric documentation states that starting without running init before will implicitly run init, something is not working fine there, and init must be called before start for things to work fine, at least when TLS is enabled.

推荐答案

Mmm ...父根CA TLS证书(受信任的根证书)应使用--intermediate.tls.certfiles指定. --tls.certfile和--tls.keyfile定义了中间CA TLS证书以及对其子级/客户端的关键方面.

Mmm... The parent root CA TLS certificate (the trusted root certificates) should be specified with --intermediate.tls.certfiles. --tls.certfile and --tls.keyfile define the intermediate CA TLS certificate and key respect to its children/clients.

设置--loglevel debug以获得更多信息(并共享).

Set --loglevel debug to get more information (and share it).

编辑:当您谈论--tls.keyfile时，要回答您的版本(我不敢评论您的帖子).我并不是说您必须使用它.我的意思是，如果使用--tls.certfile，则还必须使用--tls.keyfile，因为它们旨在通过TLS提供中间CA服务，而不是信任父根CA的TLS证书.为了您的目的，您有--intermediate.tls.certfiles. 您的命令应如下所示:

To answer to your edition (I have no reputation to comment your post), when you talk about --tls.keyfile. I don't mean that you must use it. I mean that, if you use --tls.certfile, you must also use --tls.keyfile, as they are intended to serve your intermediate CA services via TLS, not to trust your parent root CA's TLS certificate. For your purpose, you have --intermediate.tls.certfiles. Your command should look like:

fabric-ca-server start -b admin:adminpw -u https://<registered-identity>:<pw>@ca-root:7054 --intermediate.parentserver.caname ca-root --intermediate.tls.certfiles /path/to/copied/tls-cert.pem

我可能想到的错误:

  1. ca-root没有指向您的根CA.
  2. 某些防火墙规则或类似规则阻止了您的请求.
  3. 您的中间CA的端口与您的根CA的端口冲突.
  4. /path/to/copied/tls-cert.pem不是您的根CA的证书.
  5. 您的根CA的TLS证书的CN或SAN都不与域ca-root匹配.
  6. 您的根CA的配置在TLS握手期间执行客户端/相互身份验证，并且您的中间证书未使用它.
  1. ca-root does not point to your root CA.
  2. Some firewall rule or similar blocks your request.
  3. Your intermediate CA's port clashes with your root CA's port.
  4. /path/to/copied/tls-cert.pem is not your root CA's certificate.
  5. Neither of the CN or SANs of your root CA's TLS certificate matches the domain ca-root.
  6. Your root CA's configuration enforces client/mutual authentication during TLS handshake and your intermediate certificate is not using it.

如果您说它在根CA不使用TLS时有效，并且在更改过程中没有破坏其他任何事物，则它可能是4-6之一...

If you say that it worked when the root CA did not use TLS, and you have not broken any other thing during your changes, it can be one of 4-6...

这篇关于运行启用了TLS的中间CA:拒绝与根CA的连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆