File Purposes

• spiffe_cert.pem - the certificate that is placed in spiffe bundles (copied into the x5c field)
• server1_spiffe.pem - another certificate placed in spiffe bundles
• spiffe_multi_uri_san_cert.pem - another certificate placed in spiffe bundles
• spiffe-openssl.cnf - the configuration file passed to the openssl CLI when creating these certificate files
• spiffebundle.json - the valid spiffe bundle for happy path testing
• spiffebundle2.json - Another valid spiffe bundle that is used in testing file reloading (a different file is needed to ensure changes are picked up). It is just the example.com trust domain from spiffebundle.json.
• spiffebundle_corrupted_cert.json - manually modifies the x5c field and removes a character to create an invalid certificate
• spiffebundle_empty_keys.json - the keys field is an empty array
• spiffebundle_empty_string_keys.json - the keys field contains an entry
• with an empty string key
• spiffebundle_invalid_trustdomain - uses a # in the trust domain which is a disallowed character per the spec
• spiffebundle_malformed.json - a fully wrong json
• spiffebundle_match_client_spiffe.json - a valid spiffe bundle with a trust domain matching the SPIFFE ID in spiffe_cert.pem
• spiffebundle_wrong_kid.json - has the kid field instead of the kty field
• spiffebundle_wrong_kty.json - Uses EC instead of RSA in the kty field
• spiffebundle_wrong_multi_certs.json - place 2 certificates in the x5c field
• spiffebundle_wrong_root.json - The top level json string is trustDomains instead of trust_domains
• spiffebundle_wrong_seq_type.json - the spiffe_sequence number must be an integer
• spiffebundle_wrong_use.json - The use field must be x509-svid or jwt-svid (we are expecting and support x509-svid per the gRFC)

Test File Creation:

The SPIFFE related extensions are listed in spiffe-openssl.cnf config. Both client_spiffe.pem and server1_spiffe.pem are generated in the same way as the client and server certificates described in the testdata/x509 with the same CAs. Specifically they were made with the following commands:

$ openssl req -new -key client.key -out spiffe-cert.csr \
 -subj /C=US/ST=CA/L=SVL/O=gRPC/CN=testclient/ \
 -config spiffe-openssl.cnf -reqexts spiffe_client_e2e
$ openssl x509 -req -CA ca.pem -CAkey ca.key -CAcreateserial \
 -in spiffe-cert.csr -out client_spiffe.pem -extensions spiffe_client_e2e \
  -extfile spiffe-openssl.cnf -days 3650 -sha256
$ openssl req -new -key server1.key -out spiffe-cert.csr \
 -subj /C=US/ST=CA/L=SVL/O=gRPC/CN=*.test.google.com/ \
 -config spiffe-openssl.cnf -reqexts spiffe_server_e2e
$ openssl x509 -req -CA ca.pem -CAkey ca.key -CAcreateserial \
 -in spiffe-cert.csr -out server1_spiffe.pem -extensions spiffe_server_e2e \
  -extfile spiffe-openssl.cnf -days 3650 -sha256

Additionally, the SPIFFE trust bundle map files (spiffebundle*.json) are manually created for end to end testing. The spiffebundle.json contains the “example.com” trust domain (only this entry is used in e2e tests) matching URI SAN of server1_spiffe.pem, and the CA certificate there is ca.pem. The spiffebundle.json file contains “foo.bar.com” trust domain (only this entry is used in e2e tests) matching URI SAN of client_spiffe.pem, and the CA certificate there is also ca.pem.

If updating these files, the x5c field in the json is the raw PEM certificates and can be copy pasted from the certificate file. n and e are values from the public key. e should probably be AQAB as it is the exponent. n can be fetched from the certificate by getting the RSA key from the cert and extracting the value. This can be done in golang with the following codeblock:

base64.RawURLEncoding.EncodeToString(key.N.Bytes()) }

block, _ := pem.Decode(rawPemCert) cert, _ := x509.ParseCertificate(block.Bytes)
publicKey := cert.PublicKey.(*rsa.PublicKey)
fmt.Println(GetBase64ModulusFromPublicKey(publicKey)) ```

The rest of the files are manually modified as described above.