Get desktop application:
View/edit binary Protocol Buffers messages
The Certificate Management Service exported by targets. The service primarily exports two main RPCs, Install & Rotate which are used for installation of a new certificate, and rotation of an existing certificate on a target, along with a few management related RPCs.
Rotate will replace an existing Certificate on the target by creating a new CSR request and placing the new Certificate based on the CSR on the target. If the stream is broken or any steps in the process fail the target must rollback to the original Certificate. The following describes the sequence of messages that must be exchanged in the Rotate() RPC. Sequence of expected messages: Case 1: When Target generates the CSR. Step 1: Start the stream Client <---- Rotate() RPC stream begin ------> Target Step 2: CSR Client -----> GenerateCSRRequest----> Target Client <----- GenerateCSRResponse <--- Target Step 3: Certificate Signing Client gets the certificate signed by the CA. Step 4: Send Certificate to Target. Client --> LoadCertificateRequest ----> Target Client <-- LoadCertificateResponse <--- Target Step 5: Test/Validation by the client. This step should be to create a new connection to the target using The new certificate and validate that the certificate works. Once verfied, the client will then proceed to finalize the rotation. If the new connection cannot be completed the client will cancel the RPC thereby forcing the target to rollback the certificate. Step 6: Final commit. Client ---> FinalizeRequest ----> Target Case 2: When Client generates the CSR. Step 1: Start the stream Client <---- Rotate() RPC stream begin ----> Target Step 2: CSR Client generates its own certificate. Step 3: Certificate Signing Client gets the certificate signed by the CA. Step 4: Send Certificate to Target. Client ---> LoadCertificateRequest ----> Target Client <--- LoadCertificateResponse <--- Target Step 5: Test/Validation by the client. Step 6: Final commit. Client ---> FinalizeRequest ----> Target
Request messages to rotate existing certificates on the target.
Request Messages.
Response Messages from the target.
Response messages.
Install will put a new Certificate on the target by creating a new CSR request and placing the new Certificate based on the CSR on the target.The new Certificate will be associated with a new Certificate Id on the target. If the target has a pre existing Certificate with the given Certificate Id, the operation should fail. If the stream is broken or any steps in the process fail the target must revert any changes in state. The following describes the sequence of messages that must be exchanged in the Install() RPC. Sequence of expected messages: Case 1: When Target generates the CSR-------------------------: Step 1: Start the stream Client <---- Install() RPC stream begin ------> Target Step 2: CSR Client -----> GenerateCSRRequest() ----> Target Client <---- GenerateCSRResponse() <---- Target Step 3: Certificate Signing Client gets the certificate signed by the CA. Step 4: Send Certificate to Target. Client -> LoadCertificateRequest() ----> Target Client <- LoadCertificateResponse() <--- Target Case 2: When Client generates the CSR-------------------------: Step 1: Start the stream Client <---- Install() RPC stream begin ------> Target Step 2: CSR Client generates its own certificate. Step 3: Certificate Signing Client gets the certificate signed by the CA. Step 4: Send Certificate to Target. Client -> LoadCertificateRequest() ----> Target Client <- LoadCertificateResponse() <--- Target
Request messages to install new certificates on the target.
Request Messages.
Response Messages from the target for the InstallCertificateRequest.
Response messages.
An RPC to get the certificates on the target.
The request to query all the certificates on the target.
(message has no fields)
Response from the target about the certificates that exist on the target what what is using them.
An RPC to revoke specific certificates. If a certificate is not present on the target, the request should silently succeed. Revoking a certificate should render the existing certificate unusable by any endpoints.
Certificates to revoke.
List of certificates successfully revoked.
List of errors why certain certificates could not be revoked.
An RPC to ask a target if it can generate a Certificate.
A request to ask the target if it can generate key pairs.
Response from the target about whether it can generate a CSR with the given parameters.
A Certificate Signing Request.
Used in:
Type of certificate.
Bytes representing the CSR. The exact encoding depends upon the type of certificate requested. for X509: This should be the PEM encoded CSR.
Parameters to be used when generating a Certificate Signing Request.
Used in:
The type of certificate which will be associated for this CSR.
Minimum size of the key to be used by the target when generating a public/private key pair.
If provided, the target must use the provided key type. If the target cannot use the algorithm specified in the key_type, it should cancel the stream with an Unimplemented error.
--- common set of parameters applicable for any type of certificate --- //
e.g "device.corp.google.com"
e.g "US"
e.g "CA"
e.g "Mountain View"
e.g "Google"
e.g "Security"
A certificate.
Used in:
,Type of certificate.
Actual certificate. The exact encoding depends upon the type of certificate. for X509, this should be a PEM encoded Certificate.
Used in:
List of endpoints using this certificate.
System modification time when the certificate was installed/rotated in nanoseconds since epoch.
An error message indicating why a certificate id could not be revoked.
Used in:
Types of certificates.
Used in:
, , ,1 - 500 for public use. 501 onwards for private use.
An endpoint represents an entity on the target which can use a certificate.
Used in:
Human readable identifier for an endpoint.
Type of endpoint that can use a cert. This list is to be extended based on conversation with vendors.
Used in:
A Finalize message is sent to the target to confirm the Rotation of the certificate and that the certificate should not be rolled back when the RPC concludes. The certificate must be rolled back if the target returns an error after receiving a Finalize message.
Used in:
(message has no fields)
Request to generate the CSR. When this request is made for rotating an existing certificate as part of the Rotate() RPC, then the target must ensure that the "certificate_id" is already created and exists on the target. If the Certificate Rotation proceeds to load the certificate, it must associate the new certificate with the previously created "certificate_id". When this request is made for installing a completely new certificate as part of the Install() RPC , then the target must ensure that the "certificate_id" is completely new and no entities on the target are should be bound to this certificate_id. If any existing certificate matches the certificate_id, then this request should fail. If there is another ongoing Rotate/Install RPC with the same certificate_id, the GenerateCSRRequest should fail.
Used in:
,Parameters for creating a CSR.
The certificate id with which this CSR will be associated. The target configuration should bind an entity which wants to use a certificate to the certificate_id it should use.
GenerateCSRResponse contains the CSR associated with the Certificate ID supplied in the GenerateCSRRequest. When a Certificate is subsequently installed on the target in the same streaming RPC session, it must be associated to that Certificate ID. An Unimplemented error will be returned if the target cannot generate a CSR as per the request. In this case, the caller must generate its own key pair.
Used in:
,A message representing a pair of public/private keys.
Used in:
Algorithm to be used for generation the key pair.
Used in:
,1 - 500, for known types. 501 and onwards for private use.
LoadCertificateRequest instructs the target to store the given certificate. Case 1: Target Generated CSR and Key Pair. If the target generated the CSR (and the public/private key pair) during the GenerateCSR request, then the target must associate the certificate with the certificate ID specified in the preceding GenerateCSR request. Case 2: Externally Generated Key Pair. If the target can not generate a CSR, then the public/private key pair is generated externally. In this case provide the target with the key pair, and the certificate_id to be associated with the new certificate. If there is another ongoing Rotate/Install RPC with the same certificate_id, the LoadCertificateRequest must fail.
Used in:
,The certificate to be Loaded on the target.
The key pair to be used with the certificate. This is provided in the event that the target cannot generate a CSR (and the corresponding public/private keys).
Certificate Id of the above certificate. This is to be provided only when there is an externally generated key pair.
Optional bundle of CA certificates. When not empty, the provided certificates should squash the existing bundle. This field provides a simplified means to provision a CA bundle that can be used to validate other peer's certificates.
Response from target after Loading a Certificate. If the target could not load the certificate, it must end the RPC stream with a suitable RPC error about why the Certificate was not loaded.
Used in:
,(message has no fields)