Package :



Table of Contents


Specify parameters for configuring the root certificate authority for a VirtualMesh.

Field Type Label Description
vault Use vault as the intermediate CA source


CertificateRotationCondition represents a timesptamped snapshot of the certificate rotation workflow. This is used to keep track of the steps which have been completed thus far.

Field Type Label Description
timestamp string The time at which this condition was recorded
state The current state of the cert rotation
message string A human readable message related to the current condition
errors []string repeated Any errors which occurred during the current rotation stage


Field Type Label Description
none google.protobuf.Empty Verification not enabled. NOTE: This setting is only recommended for testing. When enabled rotation will continue from step to step without any kind of verification.
manual google.protobuf.Empty Verification must be completed manually. This involves using our certificate verification endpoint when the certificates are in a VERIFYING state


Configuration for generating a self-signed root certificate. Uses the X.509 format, RFC5280.

Field Type Label Description
ttlDays uint32 Number of days before root cert expires. Defaults to 365.
rsaKeySizeBytes uint32 Size in bytes of the root cert's private key. Defaults to 4096.
orgName string Root cert organization name. Defaults to “gloo-mesh”.
secretRotationGracePeriodRatio float The ratio of cert lifetime to refresh a cert. For example, at 0.10 and 1 hour TTL, we would refresh 6 minutes before expiration


State of Certificate Rotation Possible states in which a CertificateRotation can exist.

Name Number Description
NOT_ROTATING 0 No Certificate rotation is currently happening
PREVIOUS_CA 1 Signing the certificate using the previously applied CA. This step is mostly used when ADDING_NEW_ROOT fails, and the rotation has to be ROLLED_BACK
ADDING_NEW_ROOT 2 The CertificateRotation is underway, both roots are set, and the new root is being propagated
PROPAGATING_NEW_INTERMEDIATE 3 The CertificateRotation is underway again. The initial verification is over, the traffic continues to work with both roots present. Now the old root is being removed, and the new root is being propagated alone to the data-plane clusters
DELETING_OLD_ROOT 4 The CertificateRotation is underway again. Removing the old-root from all data-plane clusters
VERIFYING 5 Verifying connectivity between workloads, the workflow will not progress until connectivity has been verified. This can either be manual or in the future automated
VERIFIED 6 The connectivity has been verified.
ROLLING_BACK 7 The connectivity has been deemed to not be functioning properly, rolling back to the last known good state.
FINISHED 8 The rotation has finished, the new root has been propagated to all data-plane clusters, and traffic has been verified successfully.
FAILED 9 Processing the certificate rotation workflow failed.


Name Number Description
MULTI_ROOT 0 The default certificate rotation strategy. This strategy involves three steps which ensure that traffic in the mesh will experience no downtime. For an in depth explination of how this strategy works in Istio see the following blog The steps are as follows: 1. ADDING_NEW_ROOT During this step the new root-cert will be appended to the old root-cert, and then distributed. The intermediate will continue to be signed by the original root. 2. PROPAGATING_NEW_INTERMEDIATE During this step both root-certs will still be distributed. In addition the intermediate will now be signed by the new root key. 3. DELETING_OLD_ROOT During this step the old root is no longer included, and the intermediate will continue to be signed by the new root key.
NONE 1 Do not use any rotation strategy. NOTE: This can lead to downtime while workloads transition from one root of trust to another