google.golang.org/grpc@v1.74.2/testdata/spiffe/README.md (about)

     1  ## File Purposes
     2  
     3  *   spiffe_cert.pem - the certificate that is placed in spiffe bundles (copied
     4      into the `x5c` field)
     5  *   server1_spiffe.pem - another certificate placed in spiffe bundles
     6  *   spiffe_multi_uri_san_cert.pem - another certificate placed in spiffe bundles
     7  *   spiffe-openssl.cnf - the configuration file passed to the openssl CLI when
     8      creating these certificate files
     9  *   spiffebundle.json - the valid spiffe bundle for happy path testing
    10  *   spiffebundle2.json - Another valid spiffe bundle that is used in testing
    11      file reloading (a different file is needed to ensure changes are picked up).
    12      It is just the `example.com` trust domain from spiffebundle.json.
    13  *   spiffebundle_corrupted_cert.json - manually modifies the `x5c` field and
    14      removes a character to create an invalid certificate
    15  *   spiffebundle_empty_keys.json - the `keys` field is an empty array
    16  *   spiffebundle_empty_string_keys.json - the `keys` field contains an entry
    17  *   with an empty string key
    18  *   spiffebundle_invalid_trustdomain - uses a `#` in the trust domain which is a
    19      disallowed character per the spec
    20  *   spiffebundle_malformed.json - a fully wrong json
    21  *   spiffebundle_match_client_spiffe.json - a valid spiffe bundle with a trust
    22      domain matching the SPIFFE ID in spiffe_cert.pem
    23  *   spiffebundle_wrong_kid.json - has the `kid` field instead of the `kty` field
    24  *   spiffebundle_wrong_kty.json - Uses `EC` instead of `RSA` in the `kty` field
    25  *   spiffebundle_wrong_multi_certs.json - place 2 certificates in the `x5c`
    26      field
    27  *   spiffebundle_wrong_root.json - The top level json string is `trustDomains`
    28      instead of `trust_domains`
    29  *   spiffebundle_wrong_seq_type.json - the `spiffe_sequence` number must be an
    30      integer
    31  *   spiffebundle_wrong_use.json - The `use` field must be `x509-svid` or
    32      `jwt-svid` (we are expecting and support `x509-svid` per the gRFC)
    33  
    34  ## Test File Creation:
    35  
    36  The SPIFFE related extensions are listed in spiffe-openssl.cnf config. Both
    37  client_spiffe.pem and server1_spiffe.pem are generated in the same way as the
    38  client and server certificates described in the testdata/x509 with the same CAs.
    39  Specifically they were made with the following commands:
    40  
    41  ```
    42  $ openssl req -new -key client.key -out spiffe-cert.csr \
    43   -subj /C=US/ST=CA/L=SVL/O=gRPC/CN=testclient/ \
    44   -config spiffe-openssl.cnf -reqexts spiffe_client_e2e
    45  $ openssl x509 -req -CA ca.pem -CAkey ca.key -CAcreateserial \
    46   -in spiffe-cert.csr -out client_spiffe.pem -extensions spiffe_client_e2e \
    47    -extfile spiffe-openssl.cnf -days 3650 -sha256
    48  $ openssl req -new -key server1.key -out spiffe-cert.csr \
    49   -subj /C=US/ST=CA/L=SVL/O=gRPC/CN=*.test.google.com/ \
    50   -config spiffe-openssl.cnf -reqexts spiffe_server_e2e
    51  $ openssl x509 -req -CA ca.pem -CAkey ca.key -CAcreateserial \
    52   -in spiffe-cert.csr -out server1_spiffe.pem -extensions spiffe_server_e2e \
    53    -extfile spiffe-openssl.cnf -days 3650 -sha256
    54  ```
    55  
    56  Additionally, the SPIFFE trust bundle map files (spiffebundle*.json) are
    57  manually created for end to end testing. The spiffebundle.json contains the
    58  "example.com" trust domain (only this entry is used in e2e tests) matching URI
    59  SAN of server1_spiffe.pem, and the CA certificate there is ca.pem. The
    60  spiffebundle.json file contains "foo.bar.com" trust domain (only this entry is
    61  used in e2e tests) matching URI SAN of client_spiffe.pem, and the CA certificate
    62  there is also ca.pem.
    63  
    64  If updating these files, the `x5c` field in the json is the raw PEM certificates
    65  and can be copy pasted from the certificate file. `n` and `e` are values from
    66  the public key. `e` should *probably* be `AQAB` as it is the exponent. `n` can
    67  be fetched from the certificate by getting the RSA key from the cert and
    68  extracting the value. This can be done in golang with the following codeblock:
    69  ``` func GetBase64ModulusFromPublicKey(key *rsa.PublicKey) string { return
    70  base64.RawURLEncoding.EncodeToString(key.N.Bytes()) }
    71  
    72  block, _ := pem.Decode(rawPemCert) cert, _ := x509.ParseCertificate(block.Bytes)
    73  publicKey := cert.PublicKey.(*rsa.PublicKey)
    74  fmt.Println(GetBase64ModulusFromPublicKey(publicKey)) ```
    75  
    76  The rest of the files are manually modified as described above.