Entities: Org1 with 2 peers(peer0 & peer1), 1 Orderer, 1 IntCA.
Both peers joining a single channel
I won't be able to add files/logs or code, as it's not allowed to. Hope it's understood.
Network was initially build with peer0+CA+orderer and later peer1 was added into Org1.
Recently we renewed certificates before the expiry date. peer0 and peer1 allows transaction in, but peer1 also throws a warning/error
[peer.blocksprovider] func1 -\u003e WARN 4c87\u001b[0m Encountered an
error reading from deliver stream: rpc error: code = Canceled desc =
context canceled channel=mobileid orderer-address=orderer.xyz.com
What could be the possibility for this error(peer.blocksprovider)? could there be a mistake in cert renewal? if yes, what part could it be?
This issue was due to disabling gossip protocol within an org. Both the peers were leaders in this case and peer1 failing to disseminate blocks to peer0.
Same is not the case with peer0, which makes me think back on this.
Still no idea why this issue triggered after certificate renewal.
Related
I was testing Hyperledger-fabic v1.0.0 with kubernetes. The fabic contains 2 orgs, 4 peers, 1 orderer, and a cli. The things goes well until I instantiates the chaincode in the cli. The peer's error message in the picture. It says missing image, but the image just create successful. What's the problem and how can I solve it?
enter image description here
peer's error message
The answer can be found in the Hyperledger RocketChat on the #fabric-kubernetes channel.
"you basically need the peer to surface its dynamic IP (thats what AUTOADDRESS does) and then tell the chaincode to basically ignore the x509 CN thats what SERVERHOSTOVERRIDE does
(and the other part is you need the peer pod to be privelged so it has the rights to drive the docker-api".
Basically, there's lots to be learned from following the discussion from that point.
I have fabric composer 0.72 installed on my mac, and I was able to follow this thread to get it connected to my Blockchain (v.61 of Fabric) on Bluemix.
fabric-composer-integration-with-bluemix-blockchain-service
Now I am trying to build an ubuntu (16.04) docker container and run composer-rest-server there. When I try to connect to my blockchain service from my docker container (using the same id, WebAppAdmin, that I used on my mac) I get an error:
Discovering types from business network definition ...
Connection fails: Error: Identity or token does not match.
It will be retried for the next request.
{ Error: Identity or token does not match.
at /home/composer/.nvm/versions/node/v6.10.3/lib/node_modules /composer-rest-server/node_modules/grpc/src/node/src/client.js:417:17 code: 2, metadata: Metadata { _internal_repr: {} } }
I tried copying the cert from my mac to my docker container:
/home/composer/.composer-credentials/member.WebAppAdmin
but when I did that I got a different error that says "signature does not verify". I did some additional testing, and I discovered that if I used an id that I had not previously used with composer (i.e. user_type1_0) then I could connect, and I could see a new cert in my .composer-credentials directory.
I tried deleting that container and building a new one (I dorked something else up) I could not use that same userid again.
Does anybody know how security and these certs are supposed to work? It would seem as though something to do with certificate generation/validation is tied to the client (i.e. hardware address), such that if I try to re-use an id on a different machine, the certs or keys or something don't match. I have a way to make things work, but it doesn't seem like it's the right way if I can't use the same id from different machines.
Thanks!
Hi i tried to recreate this by having blockchain running on a unix machine and then i copied my connection profile and certificate to my mac and then edited my connection profile to update the ip address and key store. I then did a composer network ping and it worked fine.
I am using composer v0.7.4 so you could try that?
I have also faced this issue, and concluded that
There is inconsistent behavior while deploying network using composer on Cloud environment includeing Bluemix. Problem is not with composer, but with fabric 0.6.
I am assuming that this issue is also indirectly related to following known bugs into fabric 0.6, which will not be fixed in fabric 0.6.
ERROR:
"
throw er; // Unhandled 'error' event
^
Error
at ClientDuplexStream._emitStatusIfDone (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._readsDone (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:158:8)
at readCallback (/home/ubuntu/.nvm/versions/node/v6.9.5/lib/node_modules/composer-cli/node_modules/grpc/src/node/src/client.js:217:12)
"
So far, We have understood that following three JIRA are root cause , where essentially the cloud networking layer ends up killing the idle event hub connection after a period of inactivity and the fabric SDK cannot handle this.
https://jira.hyperledger.org/browse/FAB-4002 FAB-3310
https://jira.hyperledger.org/browse/FAB-3310
or FAB-2787
Conclusion:
There is no alternative way of fixing this issue with Bluemix or any cloud environment with fabric 0.6
You may not experience this issue with Fabric 1.0, but there is still possibilities as all above mentioned defects are not fixed yet.
I reinstalled some nodes and a master. Now on the master I am getting:
Sep 15 04:53:58 master kube-apiserver[803]: I0915 04:53:58.413581 803 logs.go:41] http: TLS handshake error from $ip:54337: remote error: bad certificate
Where $ip is one of the nodes.
So I likely need to delete or recreate certificates. What would the location of those be? Any recommended commands to recreate or remove those or copy them from node to master or vice versa? Whatever gets me past this error message...
Take a look through the Creating Certificates section of authentication.md. It walks you through the certificates that you need to create and how to pass them to the system components, and you should be able to use that to re-generate certificates for your cluster.
So, I'm executing this command:
cm ci -c="Merge child branch"
And, here's the response:
The selected items are about to be checked in. Please wait ...
WARNING: the secure connection hostname provided in the server
certificate doesn't match the server's hostname. This means that the
certificate was not issued to this hostname or that there is a network
configuration problem with this host.
- Certificate hostname: CN=ip-<obfuscated>
- Server hostname: CN=<obfuscated>
If you want to continue connecting to this host, choose 'Yes'. The certificate
validation will continue (not recommended).
If you want to abandon the connection, choose 'No' (recommended).
Choose an option (Y)es, (N)o (hitting Enter selects 'No'): y
The server you are connecting to has sent a certificate that is not in the
store. This is normal if it is the first time that you connect to this server.
Certificate details:
- Issued to: CN=ip-<obfuscated>
- Issued by: CN=ip-<obfuscated>
- Expiration date: 6/30/2023 6:15:40 AM
- Certificate hash:<obfuscated>
If you trust this host, choose 'Yes' to add the key to Plastic SCM's key store
(recommended if it is the first time you connect to this server).
If you want to carry on connecting just once, without adding the key to the
store, choose 'No'.
If you do not trust this host, choose 'Cancel' to abandon the connection.
Choose an option (Y)es, (N)o, (C)ancel (hitting Enter cancels): y
Assembling checkin data
Validating checkin data
Uploading file data
Confirming checkin operation
The trigger before-checkin [Comment Required] failed. .
In particular, that last line:
The trigger before-checkin [Comment Required] failed. .
But, I thought I was adding a comment. I don't think it's a syntax error. Where should I begin to debug this issue?
By the way, the same "comment required" error happens in the GUI as well even though I clearly have a comment in the comment box:
The Plastic server service I was connected to was down. In short, the first thing I should have done was contact the server administrator.
Note to self: Don't always think Stack Overflow is the only best way to solve your problems.
When trying to hit an environment with improperly configured SSL certificates, I get the following error:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:562)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
at dispatch.BlockingHttp$class.dispatch$BlockingHttp$$execute(Http.scala:45)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at dispatch.BlockingHttp$$anonfun$execute$1$$anonfun$apply$3.apply(Http.scala:58)
at scala.Option.getOrElse(Option.scala:108)
at dispatch.BlockingHttp$$anonfun$execute$1.apply(Http.scala:58)
at dispatch.Http.pack(Http.scala:25)
at dispatch.BlockingHttp$class.execute(Http.scala:53)
at dispatch.Http.execute(Http.scala:21)
at dispatch.HttpExecutor$class.x(executor.scala:36)
at dispatch.Http.x(Http.scala:21)
at dispatch.HttpExecutor$class.when(executor.scala:50)
at dispatch.Http.when(Http.scala:21)
at dispatch.HttpExecutor$class.apply(executor.scala:60)
at dispatch.Http.apply(Http.scala:21)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.tdsGet(UsersBDTest.scala:130)
at com.secondmarket.cobra.lib.delegate.UsersBDTest.setup(UsersBDTest.scala:40)
I would like to ignore the certificates entirely.
Update: I understand the technical concerns regarding improperly configured SSL certs and the issue isn't with our boxes but a service we're using. It happens mostly on test boxes rather than prod/stg so we're investigating but needed something to test the APIs.
You can't 'ignore the certificates entirely' for the following reasons:
The problem in this case is that the client didn't even provide one.
If you don't want security why use SSL at all?
I have no doubt whatsoever that many, perhaps most, of these alleged workarounds 'for development' have 'leaked' into production. There is a significant risk of deploying an insecure system if you build an insecure system. If you don't build the insecurity in, you can't deploy it, so the risk vanishes.
The following was able to allow unsafe SSL certs.
Http.postData(url, payload).options(HttpOptions.allowUnsafeSSL,
HttpOptions.readTimeout(5000))
For the newest version of Dispatch (0.13.2), you can use the following to create an http client that accepts any certificate:
val myHttp = Http.withConfiguration(config => config.setAcceptAnyCertificate(true))
Then you can use it for GET requests like this:
myHttp(url("https://www.host.com/path").GET OK as.String)
(Modify accordingly for POST requests...)
I found this out here: Why does dispatch throw "java.net.ConnectException: General SSLEngine ..." and "unexpected status" exceptions for a particular URL?
And to create an Http client that does verify the certificates, I found some sample code here: https://kevinlocke.name/bits/2012/10/03/ssl-certificate-verification-in-dispatch-and-asynchttpclient/.