Date   

Re: Getting error when invoke external chaincode

Kavin Arumugam
 

Hi Kumari,

I have tried the tutorial in the following link which was working out-of-the-box. (Used Fabric v2.2.5)
https://github.com/hyperledger/fabric-samples/tree/f84754ea3b8ea9838fb48936e9394bd54d31e54a/asset-transfer-basic/chaincode-external

Also, Thanks to Matthew for sharing the updated one.



Thanks & Regards
Kavin Arumugam
LinkedIn: @karthikkavina


On Thu, Feb 17, 2022 at 10:13 PM Matthew White <whitemat@...> wrote:

Hello;

 

The external chaincode – and specifically the external chaincode-as-a-service is a very valuable feature, and makes deployment into a cloud environment so much easier.

 

The latest Peer packaging, includes a pre-packaged core.yaml that points to a set of pre-packaged external builders. I would strongly suggest to look at the `deployCCAAS.sh` script – and specifically read this tutorial here  https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md

 

(aside we do need to move that into the docs).

 

Thanks Matthew

 

From: fabric@... <fabric@lists

 

From: fabric@... <fabric@...> On Behalf Of Kumari Shweta via lists.hyperledger.org
Sent: 17 February 2022 12:32
To: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Getting error when invoke external chaincode

 

Hi Team, I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external). I have hlf 2.2 multi host setup. step1: tar czf code.tar.gz connection.json tar czf asset-transfer-basic.tar.gz metadata.json ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Hi Team, 
I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external).
I have hlf 2.2 multi host setup.
step1: tar czf code.tar.gz connection.json
          tar czf asset-transfer-basic.tar.gz metadata.json code.tar.gz
          cp chaincode.env ../hlf_setup
step2: Added external builders into core.yaml and provided dokcer container path of external builder
step3: modify peer docker-compose and mount chaincode and core.yaml folder.
step4: up network
step5: install asset-transfer-basic.tar.gz chaincode
step 6: update chaincode id in chaincode.env
step7: create docker container for chaincode server on host1
step8: approve chaincode by all orgs
step9: commit chaincode
step10 -invoke chaincode

I am getting error when invoking chaincode ."endorserment failure during invoke.chaincode defintion exist but not installed"

Kindly suggest.

Regards,
Shweta


Re: Getting error when invoke external chaincode

Matthew White
 

Hello;

 

The external chaincode – and specifically the external chaincode-as-a-service is a very valuable feature, and makes deployment into a cloud environment so much easier.

 

The latest Peer packaging, includes a pre-packaged core.yaml that points to a set of pre-packaged external builders. I would strongly suggest to look at the `deployCCAAS.sh` script – and specifically read this tutorial here  https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md

 

(aside we do need to move that into the docs).

 

Thanks Matthew

 

From: fabric@... <fabric@lists

 

From: fabric@... <fabric@...> On Behalf Of Kumari Shweta via lists.hyperledger.org
Sent: 17 February 2022 12:32
To: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] Getting error when invoke external chaincode

 

Hi Team, I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external). I have hlf 2.2 multi host setup. step1: tar czf code.tar.gz connection.json tar czf asset-transfer-basic.tar.gz metadata.json ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Hi Team, 
I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external).
I have hlf 2.2 multi host setup.
step1: tar czf code.tar.gz connection.json
          tar czf asset-transfer-basic.tar.gz metadata.json code.tar.gz
          cp chaincode.env ../hlf_setup
step2: Added external builders into core.yaml and provided dokcer container path of external builder
step3: modify peer docker-compose and mount chaincode and core.yaml folder.
step4: up network
step5: install asset-transfer-basic.tar.gz chaincode
step 6: update chaincode id in chaincode.env
step7: create docker container for chaincode server on host1
step8: approve chaincode by all orgs
step9: commit chaincode
step10 -invoke chaincode

I am getting error when invoking chaincode ."endorserment failure during invoke.chaincode defintion exist but not installed"

Kindly suggest.

Regards,
Shweta


Re: External chaincode implementation

Matthew White
 

Hello;

 

The external chaincode – and specifically the external chaincode-as-a-service is a very valuable feature, and makes deployment into a cloud environment so much easier.

 

The latest Peer packaging, includes a pre-packaged core.yaml that points to a set of pre-packaged external builders. I would strongly suggest to look at the `deployCCAAS.sh` script – and specifically read this tutorial here  https://github.com/hyperledger/fabric-samples/blob/main/test-network/CHAINCODE_AS_A_SERVICE_TUTORIAL.md

 

(aside we do need to move that into the docs).

 

Thanks Matthew

 

From: fabric@... <fabric@...> On Behalf Of jeff.jo95z@...
Sent: 17 February 2022 14:10
To: fabric@...
Subject: [EXTERNAL] [Hyperledger Fabric] External chaincode implementation

 

hello, I was trying to implement an external chaincode.But got the following errors. Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock er build failed: ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
hello,
I was trying to implement an external chaincode.But got the following errors.

Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock

er build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: EXTERNAL

Adding core.yaml and docker-compose file along with this

I have executed 

chmod 777 -R bin/

on building scripts


Event: Documentation Workgroup monthly call - 02/18/2022 #cal-reminder

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Reminder: Documentation Workgroup monthly call

When:
02/18/2022
11:00am to 12:00pm
(UTC-05:00) America/New York

Where:
Zoom Room - https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer: Josh Horton joshh@...

View Event

Description:
Schedule, Agendas, Minutes, etc: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Re: how core peer address works

jkneubuh@...
 

Hi Nikos,

Gateway applications can run either locally on the host OS or within the K8s as a container.  In development cycles you can build/edit/test your application locally (e.g. in a debugger) on the host OS, and then over time migrate your application to run within Kubernetes as a container.   Both cases are supported, and encouraged!  When running a gateway application "locally" you will need to either open a port forward to the target Gateway peer Service, or set up an Ingress to tunnel over the Nginx controller into the peers.  When running within Kubernetes, the application can reach the gateway peers via the Kube internal network. 

Depending on your preference both the port forward and Ingress routes work really well.  We haven't done a good job of documenting this, but our team frequently uses the *.vcap.me and *.<ip-address-with-dash>.nip.io DNS wildcard aliases to access the nginx ingress controller for access into the test network.   For instance, you can add the host alias "my-gateway-service.vcap.me" to the peer Certificate requests (see the SAN sections in the kube/../orgX-peerY.yaml), then set up a k8s Ingress to route traffic to the Gateway peer Service.   When you open a TCP connection from your host OS, you can open a connection to grpcs://my-gateway-service.vcap.me, which in turn resolves to 127.0.0.1 and routes through the Ingress.    This is too "fiddly" for inclusion in the CI test suite, so on that path we use a temporary port forward and accesse the gateways via a localhost URL. 

Once in production (or at least in a container), your application can be set up via Deployment and then reference the gateway service directly within Kubernetes.  E.g. grpcs://my-gateway-service. 

Regarding the shell scripting and administration, I agree that the preferred approach is to set up the network without any scripting.  For kube test network we tried to keep this as simple as possible, and map to the existing patterns based on the Docker Compose test network.  If you are looking for a more "production-ready" deployment for working with Fabric, it is highly recommended to use a software-based approach such as the Fabric Operations Console, Hyperledger Ansible Playbooks, Blockchain Automation Framework, IBM Hyperledger Support, etc. to reduce complexity for your network installation and administration tasks.

-josh


Expired certificates and orderers not running using handshake time shift #fabric-questions #hyperledger-fabric #tls #signcerts

afrancoc2000@...
 

Hy everyone,

I'm having a problem with expired certificates, I'm running a cluster with several channels and I updated the certificates on time for most of them, but I forgot about a channel that was created and used only during the first initialization of the cluster.
 
So today in my test environment the orderers got restarted and now they don't start, my production environment has the same problem but as they haven't been restarted they are running as if nothing has changed, for now.
 
So, I did as it is said, in this issue and changed these environment variables:
 
- ORDERER_GENERAL_AUTHENTICATION_NOEXPIRATIONCHECKS: "true"
- ORDERER_GENERAL_CLUSTER_TLSHANDSHAKETIMESHIFT: 96h
- ORDERER_GENERAL_TLS_TLSHANDSHAKETIMESHIFT: 96h
- ORDERER_OPERATIONS_TLS_TLSHANDSHAKETIMESHIFT: 96h
- ORDERER_ADMIN_TLS_TLSHANDSHAKETIMESHIFT: 96h
 
The only handshake time shift still missing is the one from kafta that I don't use, I'm using Raft, but still, I'm getting this error trying to run the orderers:
 
PANI 00d Error creating ledger resources: error creating channelconfig bundle: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: CA Certificate is not valid, (SN: 512917139581241201287378615618194486727802882): could not obtain certification chain: the supplied identity is not valid: x509: certificate has expired or is not yet valid: current time 2022-02-17T14:28:20Z is after 2022-02-16T16:41:01Z
 
I didn't change the public keys of any of the certificates, just created new ones with a new expiration date, and I have already updated them in the msp folders, the thing was that my ICA certificate was also updated, but the old one in the channel configuration is still valid, the ones that expired are not any of the CA ones.
 
Things were working yesterday even restarted the environment a couple of times so a time shift of 96 hours should work, I'm not sure what else to change.

What else can I change to be able to update the channel configuration and at least be able to run my orderers?

Thank you very much

Ana Maria Franco
Tech Leader Ceiba Software


Re: how core peer address works

Nikos Karamolegkos
 

About k8s where the typescript application runs? I had the impression that is running inside the k8s cluster. Am I wrong? Is it running locally?

In general, I prefer to use the Gateway client to connect to the fabric network however I have understand that the client application are used for query and updating the ledger. So my question was 1) how to setup the entire network without using any bash script (which is the ideal occasion) 2) how to manage the network  (add new channels, and installing/updating chaincodes) after creating it (even if the deployment has take place using bash)


Re: Hyperledger Fabric Gateway fails with certificate signed by unknown authority but certificates pass an openssl test #hyperledger-fabric #tls #fabric-sdk-go

afrancoc2000@...
 

So the issue was resolved with the help of the Hyperledger team here
Thank you, all 


External chaincode implementation

jeff.jo95z@...
 

hello,
I was trying to implement an external chaincode.But got the following errors.

Error: chaincode install failed with status: 500 - failed to invoke backing implementation of 'InstallChaincode': could not build chaincode: dock
er build failed: platform builder failed: Failed to generate a Dockerfile: Unknown chaincodeType: EXTERNAL

Adding core.yaml and docker-compose file along with this

I have executed 

chmod 777 -R bin/

on building scripts


Getting error when invoke external chaincode

Kumari Shweta
 

Hi Team, 
I am implementing external chaincode service using sample chaincode (asset-transfer-basic/chaincode-external).
I have hlf 2.2 multi host setup.
step1: tar czf code.tar.gz connection.json
          tar czf asset-transfer-basic.tar.gz metadata.json code.tar.gz
          cp chaincode.env ../hlf_setup
step2: Added external builders into core.yaml and provided dokcer container path of external builder
step3: modify peer docker-compose and mount chaincode and core.yaml folder.
step4: up network
step5: install asset-transfer-basic.tar.gz chaincode
step 6: update chaincode id in chaincode.env
step7: create docker container for chaincode server on host1
step8: approve chaincode by all orgs
step9: commit chaincode
step10 -invoke chaincode

I am getting error when invoking chaincode ."endorserment failure during invoke.chaincode defintion exist but not installed"

Kindly suggest.

Regards,
Shweta



Re: Consenter Certificate Updates When Using a Third-Party CA

Robert Broeckelmann
 

Yacov,

Thanks for responding. As I noted in my last post, I was able to fix my problem.

I saw your response. I tried updating my Issuing CA certificates for the OrdererOrg to have OU=orderer. THere was no difference. I also tried no OU and a completely random OU on the Issuing CA certificate. It didn't seem to matter. I tried this on both the TLS Issuing CA and the digital signature Issuing CA certificates.

All Issuing CA certificates (both original and new) were from a third-party CA and had no OU defined in my original solution. What I'm planning to move forward with has no OU in the Issuing CA DNs for any org.



------- Original Message -------
On Tuesday, February 1st, 2022 at 11:47 AM, Yacov Manevich <YACOVM@...> wrote:
Maybe on the application channel, the orderer MSP has an OU configured and your identity you used to submit the transaction was issued by a CA with a different OU?

From: fabric@... <fabric@...> on behalf of Robert Broeckelmann <robert@...>
Sent: Tuesday, February 1, 2022 8:45 PM
To: fabric@... <fabric@...>
Subject: [EXTERNAL] [Hyperledger Fabric] Consenter Certificate Updates When Using a Third-Party CA
 
I have a blockchain network with four organizations working with crypto material generated with cryptogen. I also have it working with crypto material generated from a third-party certificate authority that's introduced during initial creation ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I have a blockchain network with four organizations working with crypto material generated with cryptogen. I also have it working with crypto material generated from a third-party certificate authority that's introduced during initial creation of the network. Using the same third-party CA, I'm now trying to update issuing CAs and regenerate all the certificates (out of the new issuing CAs) on an existing blockchain network. I have created a script that updates the TLS & Digital Signature Issuing CA certificates for the OrdererOrg in an existing blockchain network. The Issuing CA certificates are updated in the system-channel and the application channel. This appears to be successful. I generate new certificates (TLS, Digital Signature, Admin) and update the channel configuration for each channel. THat also appears to be successful. Then, I have to update the consenter certificates in each channel. I update the consenter certificates one orderer at a time, in its own transaction. To be more specific, the following updates are made in each transaction for the consenter certificates:

system-channel:
  cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
       > ${TMP_DIR}/modified-${neworg}-root.json

app-channel:
  cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
        > ${TMP_DIR}/modified-${neworg}-root.json

There are five orderers in my OrdererOrg using the RAFT Orderer. For app-channel, Block 12 contains the configuration update transaction to update the consenter certificate for orderer0, Block 13 contains the transaction for updating the consenter certificate info for orderer1, etc,etc to Block 16 for consenter certificate of orderer4.

The system-channel transactions seem to be validated without issue. For the app-channel, all transactions that update the consenter certificates produce the following error on each peer:

[[34m2022-01-31 20:29:09.642 UTC [gossip.privdata] StoreBlock -> INFO 032^[[0m Received block [12] from buffer channel=app-channel^M
^[[31m2022-01-31 20:29:09.644 UTC [protoutils] ValidateTransaction -> ERRO 033^[[0m checkSignatureFromCreator returns err creator certificate is not valid: could not validate identity's OUs: certifiersIdentifier does not match: [orderer(6BF380B427FE7D15)], MSP: [OrdererMSP]^M
^[[31m2022-01-31 20:29:09.644 UTC [committer.txvalidator] validateTx -> ERRO 034^[[0m Invalid transaction with index 0^M
^[[34m2022-01-31 20:29:09.644 UTC [committer.txvalidator] Validate -> INFO 035^[[0m [app-channel] Validated block [12] in 2ms^M
^[[33m2022-01-31 20:29:09.644 UTC [validation] preprocessProtoBlock -> WARN 036^[[0m Channel [app-channel]: Block [12] Transaction index [0] TxId [] marked as invalid by committer. Reason code [BAD_CREATOR_SIGNATURE]^M
^[[34m2022-01-31 20:29:09.669 UTC [kvledger] CommitLegacy -> INFO 037^[[0m [app-channel] Committed block [12] with 1 transaction(s) in 24ms (state_validation=0ms block_and_pvtdata_commit=7ms state_commit=15ms) commitHash=[64eccde911898a82e6d767b4ca13099c3d5594bde5d418bb1cb883d339b8cd94]^M

What does the hex # in "orderer(6BF380B427FE7D15)" represent?

My config.yaml on the peers and orderers contains:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.org1.example.org-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.org2.example.org-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.org3.example.org-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.org4.org4.example.org-cert.pem
    OrganizationalUnitIdentifier: orderer

For the consenter (TLS) certificate for the orderers, I've tried with OU=orderer and no OU in the Subject DN. The results were the same.

I'm not sure if there is something wrong with the certificates I'm generating, the order I'm updating the channel configuration for the consenter certificates, or the config changes I'm making. Any ideas?


Re: Consenter Certificate Updates When Using a Third-Party CA

Robert Broeckelmann
 

Good news. I was able to succesfully update the consenter certificates for all five of my RAFT orderer nodes. I got this working a couple of days ago.

I wanted to share what I found. Mainly because I'm very curious if there is a more straightforward way of doing this.

Before I attempt to update the consenter certificates in the application channel, I do the following:
I generate a new Digital Signature CA certificate/key and TLS CA certificate/key. For testing purposes, I'm using openssl to do this.
I generate all the new certificates (signed by the corresponding CA certs from the last step) needed for the orderers. This includes a dsig cert, tls cert, and admin cert for each orderer. The private keys are regenerated as well.
All of these certs/keys are placed in the appropriate places in the crypto-config directory for each orderer.
The system-channel configuration is updated successfully without issue.
Then, I update the application channel configuration with the Issuing CAs and certs I generated. I originally, was updating the application channel at this step with the following JQ expression:

'.channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.root_certs += ["'${DSIG_CA_ENCODED}'"] |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.admins += ["'${ADMIN_CERT_ENCODED}'"] |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.client_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.orderer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |       
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.peer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |       
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.admin_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |       
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.tls_root_certs += ["'${TLS_CA_ENCODED}'"]'

After enabling debug on the protoutils module, I got the following log entries (note, I have trimmed out the full certificate and channel name):

2022-02-16 09:44:06.431 UTC [gossip.privdata] StoreBlock -> INFO 05e Received block [13] from buffer channel=app-channel
2022-02-16 09:44:06.431 UTC [protoutils] ValidateTransaction -> DEBU 05f ValidateTransactionEnvelope starts for envelope 0xc004d30410
2022-02-16 09:44:06.431 UTC [protoutils] ValidateTransaction -> DEBU 060 Header is channel_header:"\010...\"\r..." signature_header:"\n\321\n\n\nOrdererMSP\022\302\n-----BEGIN CERTIFICATE-----\nMIIDt...-----END CERTIFICATE-----\n\022...365"
2022-02-16 09:44:06.431 UTC [protoutils] validateChannelHeader -> DEBU 061 validateChannelHeader info: header type 1
2022-02-16 09:44:06.431 UTC [protoutils] checkSignatureFromCreator -> DEBU 062 begin
2022-02-16 09:44:06.432 UTC [protoutils] checkSignatureFromCreator -> DEBU 063 creator is &{OrdererMSP 956707729a2593b00cc66ca1ca8c9978c9304a2c3219c6c21cad9fce656c6c98}
2022-02-16 09:44:06.432 UTC [protoutils] ValidateTransaction -> ERRO 064 checkSignatureFromCreator returns err creator certificate is not valid: could not validate identity's OUs: certifiersIdentifier does not match: [orderer(65EE5DB1234EEE0E)], MSP: [OrdererMSP]
2022-02-16 09:44:06.432 UTC [committer.txvalidator] validateTx -> ERRO 065 Invalid transaction with index 0

So, the "creator certificate" in this case is the original digital signature certificate for our orderer0 node, which makes sense since the original certificate is still being used and this is the transaction that is supposed to introduce the new certificates to the channel configuration. Among the configuration elements being updated in this transaction is "fabric_node_ous.orderer_ou_identifier.certificate". So, I'm introducing the new digital signature CA certificate there. If I remove the update to this configuration element from the transaction and wait until the last orderer consenter certificate update to add it, then things start working as desired. I found this by temperarily removing each field update being made to the channel configuration that references the digital signature CA for the OrdererOrg (one at a time).

So, the application channel configuration update now looks like:

'.channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.root_certs += ["'${DSIG_CA_ENCODED}'"] |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.admins += ["'${ADMIN_CERT_ENCODED}'"] |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.client_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.peer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.admin_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.tls_root_certs += ["'${TLS_CA_ENCODED}'"]'

So, now the original ordererOrg digital signature CA cert is still trusted when the consenter certificates are being updated. So, the original error about BAD_CREATOR_SIGNATURE goes away and the new consenter certificate is accepted by each peer.

In the final consenter certificate update transaction, I add the orderer OU CA certificate update as well with:

  if [ ${ELEMENT} -eq 4 ];
  then
    cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.groups.OrdererOrg.values.MSP.value.config.fabric_node_ous.orderer_ou_identifier.certificate ="'${DSIG_CA_ENCODED}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
        > ${TMP_DIR}/modified-${neworg}-root.json
  else
    cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
        > ${TMP_DIR}/modified-${neworg}-root.json
  fi

This completes the updates required to change out the Issuing CAs for the OrdererOrg.

Is there an easier way to do this? There are several non-obvious steps here.

------- Original Message -------
On Tuesday, February 1st, 2022 at 10:45 AM, Robert Broeckelmann <robert@...> wrote:

I have a blockchain network with four organizations working with crypto material generated with cryptogen. I also have it working with crypto material generated from a third-party certificate authority that's introduced during initial creation of the network. Using the same third-party CA, I'm now trying to update issuing CAs and regenerate all the certificates (out of the new issuing CAs) on an existing blockchain network. I have created a script that updates the TLS & Digital Signature Issuing CA certificates for the OrdererOrg in an existing blockchain network. The Issuing CA certificates are updated in the system-channel and the application channel. This appears to be successful. I generate new certificates (TLS, Digital Signature, Admin) and update the channel configuration for each channel. THat also appears to be successful. Then, I have to update the consenter certificates in each channel. I update the consenter certificates one orderer at a time, in its own transaction. To be more specific, the following updates are made in each transaction for the consenter certificates:

system-channel:
  cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
       > ${TMP_DIR}/modified-${neworg}-root.json

app-channel:
  cat ${TMP_DIR}/config.json | jq '.channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].client_tls_cert = "'${ENCODED_CERT}'" |
        .channel_group.groups.Orderer.values.ConsensusType.value.metadata.consenters['${ELEMENT}'].server_tls_cert = "'${ENCODED_CERT}'"' \
        > ${TMP_DIR}/modified-${neworg}-root.json

There are five orderers in my OrdererOrg using the RAFT Orderer. For app-channel, Block 12 contains the configuration update transaction to update the consenter certificate for orderer0, Block 13 contains the transaction for updating the consenter certificate info for orderer1, etc,etc to Block 16 for consenter certificate of orderer4.

The system-channel transactions seem to be validated without issue. For the app-channel, all transactions that update the consenter certificates produce the following error on each peer:

[[34m2022-01-31 20:29:09.642 UTC [gossip.privdata] StoreBlock -> INFO 032^[[0m Received block [12] from buffer channel=app-channel^M
^[[31m2022-01-31 20:29:09.644 UTC [protoutils] ValidateTransaction -> ERRO 033^[[0m checkSignatureFromCreator returns err creator certificate is not valid: could not validate identity's OUs: certifiersIdentifier does not match: [orderer(6BF380B427FE7D15)], MSP: [OrdererMSP]^M
^[[31m2022-01-31 20:29:09.644 UTC [committer.txvalidator] validateTx -> ERRO 034^[[0m Invalid transaction with index 0^M
^[[34m2022-01-31 20:29:09.644 UTC [committer.txvalidator] Validate -> INFO 035^[[0m [app-channel] Validated block [12] in 2ms^M
^[[33m2022-01-31 20:29:09.644 UTC [validation] preprocessProtoBlock -> WARN 036^[[0m Channel [app-channel]: Block [12] Transaction index [0] TxId [] marked as invalid by committer. Reason code [BAD_CREATOR_SIGNATURE]^M
^[[34m2022-01-31 20:29:09.669 UTC [kvledger] CommitLegacy -> INFO 037^[[0m [app-channel] Committed block [12] with 1 transaction(s) in 24ms (state_validation=0ms block_and_pvtdata_commit=7ms state_commit=15ms) commitHash=[64eccde911898a82e6d767b4ca13099c3d5594bde5d418bb1cb883d339b8cd94]^M

What does the hex # in "orderer(6BF380B427FE7D15)" represent?

My config.yaml on the peers and orderers contains:

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca.org1.example.org-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca.org2.example.org-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca.org3.example.org-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca.org4.org4.example.org-cert.pem
    OrganizationalUnitIdentifier: orderer

For the consenter (TLS) certificate for the orderers, I've tried with OU=orderer and no OU in the Subject DN. The results were the same.

I'm not sure if there is something wrong with the certificates I'm generating, the order I'm updating the channel configuration for the consenter certificates, or the config changes I'm making. Any ideas?


Re: Fabric protobuf upgrade PR

Antoine Toulme <atoulme@...>
 

Hi everyone,

The PR is ready for another round of review. The tests pass and Param has checked off the migration scenarios.


Please take a good look.

Cheers,

Antoine

On Jan 12, 2022, at 11:07 AM, Antoine Toulme <atoulme@...> wrote:

Hey folks,

I think I’m close, maybe, to finish the work on the Protobuf upgrade. I am stumped right now with the CI - unit tests do not pass, but only on the CI build.

The message displayed is a bit puzzling to me:
Running Suite: Etcdraft Suite

=============================

Random Seed: 1641934238
Will run 1 of 123 specs
<snip test logs>
Ran 1 of 123 Specs in 0.434 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 122 Skipped
PASS | FOCUSED
Ran 1 of 123 Specs in 0.434 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 122 Skipped
PASS | FOCUSED

It is unclear to me why or whether the specs fail.

Would someone with astute eyes be willing to review the logs? The full output is there:

Thank you!

Antoine


Re: how core peer address works

jkneubuh@...
 

Hi Nikos,

By all means please use the new Gateway client when connecting an application to a Fabric network.  The new SDKs provide a single URL for access to the ledger, making for a very convenient bridge into the network.

Good examples of the gateway SDK in action can be found at application-gateway-go and application-gateway-typescript

For discovery in K8s, the typescript application is also set up to read input parameters (cert paths, host names, etc.) from the incoming environment.  It's still a little rough but an example that runs the typescript application locally with the Kube test network is at ci/scripts/run-k8s-test-network-basic.sh.   When connecting the gateway client in Kubernetes, we can set up a kube Service instance fronting multiple peers in the network.  See @charalarg 's recent PR #639 and Issue #635 to see this in action, and HIGH_AVAILABILITY for a little additional context.  

Cheers and happy coding,
-josh


Re: how core peer address works

Nikos Karamolegkos
 

Any information on that?


Fabric Contributor Meeting - February 16, 2022 - CANCELLED

David Enyeart
 

Fabric contributor meeting cancelled this week, no agenda topics.

 

Please send any agenda topics for March 2nd meeting to this mail list.

 


Cancelled Event: Fabric Contributor Meeting - Wednesday, February 16, 2022 #cal-cancelled

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Cancelled: Fabric Contributor Meeting

This event has been cancelled.

When:
Wednesday, February 16, 2022
9:00am to 10:00am
(UTC-05:00) America/New York

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer: Dave Enyeart enyeart@...

Description:
For meeting agendas, recordings, and more details, see https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

Join Zoom Meeting
https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09
 
Meeting ID: 518 494 7650
Passcode: 475869


Fabric Documentation workgroup monthly call Friday 2/18

Josh Horton
 

By:
Josh Horton
When:
Friday, February 18th, 2022
11:00am to 12:00pm
(UTC-05:00) Eastern Time - New York (EST)
Repeats:
Every 4 weeks on Friday
Where:
Zoom Room - https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09
Organizer:
Josh Horton joshh@...
Description:
Schedule, Agendas, Minutes, etc: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Now: Private Chaincode Lab - 02/15/2022 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
02/15/2022
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer: Marcus Brandenburger bur@...

View Event

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Virtual meetup about using Kubernetes with Hyperledger Fabric on Feb 23 at 16:00 UTC

David Boswell <dboswell@...>
 

On Wednesday, Feb 23 @ 16:00 UTC you're invited to a virtual meetup that will look at the possibilities of using Hyperledger Fabric with Kubernetes.  Since this is a virtual meetup, anyone anywhere is welcome to dial-in.  Details are at:


And if anyone here is interested in speaking about the work you're doing with Fabric at a meetup, let me know and I'll be happy to help you organize and promote an event.

Thanks,
David