user13: With reference to my previous question regarding inconsistent reading of KES validity given by cardano-node and gLiveView, is there any way I could objectively verify KES validity without waiting for the next block?

user6632: Try the 2 commands below to see if they give you the info that you need.
1 - Cardano version 1.34.0 (and 1.34.1?) has a bug that does not show KES calculations correctly - this should be fixed in 1.35.0. Below is from 1.34.1 after I did a KES rotation earlier today.
$cardano-cli query kes-period-info --mainnet --op-cert-file op.cert

✓ The operational certificate counter agrees with the node protocol state counter
✓ Operational certificate's kes period is within the correct KES period interval
{
    "qKesNodeStateOperationalCertificateNumber": 14,
    "qKesCurrentKesPeriod": 505,
    "qKesOnDiskOperationalCertificateNumber": 15,
    "qKesRemainingSlotsInKesPeriod": 6783509,
    "qKesMaxKESEvolutions": 62,
    "qKesKesKeyExpiry": "2022-09-22T21:44:51Z",
    "qKesEndKesInterval": 558,
    "qKesStartKesInterval": 496,
    "qKesSlotsPerKesPeriod": 129600
}

2 - Try using the localhost HTTP metrics details via CLI - note your port number may vary:
$curl -s 127.0.0.1:12798/metrics | grep KES

cardano_node_metrics_operationalCertificateExpiryKESPeriod_int 567 
cardano_node_metrics_currentKESPeriod_int 505 
cardano_node_metrics_remainingKESPeriods_int 62 
cardano_node_metrics_operationalCertificateStartKESPeriod_int 505


user252: Things you can verify:

Current opcert counter is higher than previous counter on chain in a block created by your pool (you can use dbsync or query a public instance) - you already saw in your previous thread that expected OCert for your node was 6). Starting Vasil fork, it is expected that - upon rotation, your opcert counter is higher by exactly 1
Expiry date of KES  (can query EKG or also just check gLiveView).
Make sure your cert was derived using kes from your cold key using which pool was created.

Once each of above is verified, it's simply a matter of waiting for your next block to get the proof/assurance. The above are pretty much the only checks you can perform.

13: <p>With reference to my previous question regarding <a href="https://cardano.stackexchange.com/questions/2051/invalid-kes-signature-ocert-but-gliveview-shows-kes-is-valid">inconsistent reading of KES validity</a> given by cardano-node and gLiveView, is there any way I could objectively verify KES validity without waiting for the next block?</p>
 6632: <p>Try the 2 commands below to see if they give you the info that you need.</p>
<p>1 - Cardano version 1.34.0 (and 1.34.1?) has a bug that does not show KES calculations correctly - this should be fixed in 1.35.0. Below is from 1.34.1 after I did a KES rotation earlier today.</p>
<pre><code>$cardano-cli query kes-period-info --mainnet --op-cert-file op.cert

✓ The operational certificate counter agrees with the node protocol state counter
✓ Operational certificate's kes period is within the correct KES period interval
{
    &quot;qKesNodeStateOperationalCertificateNumber&quot;: 14,
    &quot;qKesCurrentKesPeriod&quot;: 505,
    &quot;qKesOnDiskOperationalCertificateNumber&quot;: 15,
    &quot;qKesRemainingSlotsInKesPeriod&quot;: 6783509,
    &quot;qKesMaxKESEvolutions&quot;: 62,
    &quot;qKesKesKeyExpiry&quot;: &quot;2022-09-22T21:44:51Z&quot;,
    &quot;qKesEndKesInterval&quot;: 558,
    &quot;qKesStartKesInterval&quot;: 496,
    &quot;qKesSlotsPerKesPeriod&quot;: 129600
}
</code></pre>
<p>2 - Try using the localhost HTTP <code>metrics</code> details via CLI - note your port number may vary:</p>
<pre><code>$curl -s 127.0.0.1:12798/metrics | grep KES

cardano_node_metrics_operationalCertificateExpiryKESPeriod_int 567 
cardano_node_metrics_currentKESPeriod_int 505 
cardano_node_metrics_remainingKESPeriods_int 62 
cardano_node_metrics_operationalCertificateStartKESPeriod_int 505
</code></pre>
 252: <p>Things you can verify:</p>
<ul>
<li>Current opcert counter is higher than previous counter on chain in a block created by your pool (you can use dbsync or query a public instance) - you already saw in your previous thread that expected OCert for your node was 6). Starting Vasil fork, it is expected that - upon rotation, your opcert counter is higher by <em>exactly 1</em></li>
<li>Expiry date of KES  (can query EKG or also just check gLiveView).</li>
<li>Make sure your cert was derived using kes from your cold key using which pool was created.</li>
</ul>
<p>Once each of above is verified, it's simply a matter of waiting for your next block to get the proof/assurance. The above are pretty much the only checks you can perform.</p>
