[FAB-18188] Log orderer and peer cert expiration date upon startup

[denyeart]

Type of change

• Improvement (improvement to logging)

Description

FAB-17000 added a warning if expiration is within a week.

This change additionally info logs the future enrollment, tls server, and tls client
cert expiration dates upon startup, regardless of whether they will expire within a week or not.

Signed-off-by: David Enyeart enyeart@us.ibm.com

[yacovm]

I don't understand why modify the current code and make it even more complex.

Why not just export certExpirationTime and log it outside?

[denyeart]

@yacovm Because each of the three certs have checks against them in TrackExpiration, as does certExpirationTime(). Why duplicate all those checks and add complexity to the peer and orderer mains, when it can be done together with the existing logging in the dedicated expiration tracking function where people would expect it. At the end of the day, I don't think it matters much either way, but mostly I'd prefer to keep the mains nice and clean.

[yacovm]

@yacovm Because each of the three certs have checks against them in TrackExpiration, as does certExpirationTime(). Why duplicate all those checks and add complexity to the peer and orderer mains, when it can be done together with the existing logging in the dedicated expiration tracking function where people would expect it. At the end of the day, I don't think it matters much either way, but mostly I'd prefer to keep the mains nice and clean.

I think that if you make a single function that accepts all 3 as inputs (similar to track expiration) then it won't pollute the main, and will be much easier to understand the code.

[denyeart]

@yacovm Because each of the three certs have checks against them in TrackExpiration, as does certExpirationTime(). Why duplicate all those checks and add complexity to the peer and orderer mains, when it can be done together with the existing logging in the dedicated expiration tracking function where people would expect it. At the end of the day, I don't think it matters much either way, but mostly I'd prefer to keep the mains nice and clean.

I think that if you make a single function that accepts all 3 as inputs (similar to track expiration) then it won't pollute the main, and will be much easier to understand the code.

@yacovm But all three cert expiration dates are not available for logging, it depends on which are configured on the node. By the time we duplicate that logic, might as well just log it alongside the expiration Warning where I have it. I'm not seeing the complexity of keeping the expiration warning and expiration logging co-located in trackCertExpiration(), on the contrary it seems that a trackCertExpiration() function is the most straightforward place to both log the date and provide a warning if the date is coming soon.

[denyeart]

@Mergifyio backport release-2.2

[denyeart]

@Mergifyio backport release-2.1

[denyeart]

@Mergifyio backport release-2.0

[mergify]

Command backport release-2.2: success

Backports have been created

• #1806 [FAB-18188] Log orderer and peer cert expiration date upon startup (bp #1804) has been created for branch release-2.2

[mergify]

Command backport release-2.1: success

Backports have been created

• #1807 [FAB-18188] Log orderer and peer cert expiration date upon startup (bp #1804) has been created for branch release-2.1

[mergify]

Command backport release-2.0: success

Backports have been created

• #1808 [FAB-18188] Log orderer and peer cert expiration date upon startup (bp #1804) has been created for branch release-2.0