-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No TLSHANDSHAKETIMESHIFT for intermediate Ca Certificates #3238
Comments
The problem is not that the TLS handshake timeshift is not honored by the channel config, but rather that the MSP setup of TLS CA certificates (or the setup of enrollment CAs) doesn't use the same trick that is used for identities. This means that if any CA certificate in the network (present in the channel config) expired, all nodes (orderers and peers alike) will forever be in a crash loop. I think we should use the same time override that we do for validating identities in the TLS (and regular) CA setup in the MSP. Thoughts? @denyeart @adecaro @ale-linux |
@afrancoc2000 do you mind editing your issue and putting the entire stack trace so it will be more evident what the problem is? |
Sure @yacovm, here's the entire stack trace:
Also I added it to the description |
@yacovm Yes, I think we need a timeshift for regular CA and TLS CA verification. Instead of all of these different timeshift options, what would you think of a single global timeshift that would apply to all of them? Users have a difficult time keeping track of all the different certs and which overrides apply to which ones. |
Please click on the links in my comment and read the code and understand why a "global time shift" or |
@yacovm |
The former, of course. The no expiration checks is a check for validation in the admission path of transactions. |
Ok, I agree with the proposal. |
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]> Signed-off-by: Ana Maria Franco Cuesta <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]>
Hi All, Just a comment here to make sure everything is in context. Having said that, it must be clear that the administrators of the Fabric network must ensure that all CA certificates used in the current epoch are not expired. Fabric cannot check that, it must be done manually or with other automated processes. |
But the TLS CA certificates are not going to be used by the channel config at all. |
Signed-off-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4)
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4)
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4) Co-authored-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4) Co-authored-by: Ana Maria Franco <[email protected]>
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4)
Fix backported to release-2.4, release-2.3, release-2.2. |
Signed-off-by: Ana Maria Franco <[email protected]> (cherry picked from commit 0e6c8d4) Co-authored-by: Ana Maria Franco <[email protected]>
It also affects Fabric 1.4.x ? Looks like the shift gets nor applied on the for the root CA. |
@rodolfoleal Fabric v1.4 is out of maintenance. There are many issues with v1.4 that have been fixed only in v2.x. Users must upgrade to v2.x to get these fixes. |
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:
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 published the issue in the message channel and with the help of @yacovm found that there's no TLS Handshake time shift for the CA certificates.
Here's the stack trace:
Thanks
The text was updated successfully, but these errors were encountered: