findLeafCertifications causes missing data on bundled self signed certs

[robschn]

Heya team!

We found through testing that there may be an issue with our self signed certs not populating the Serial field in services/haproxy/storage/ssl_certificates calls.

We think this bit of logic might have something to do with it but not sure exactly.

The RunTimeAPI calls seem to contain all the info

❯ curl -s --user xxxx:xxxx "http://127.0.0.1:xxxx/v3/services/haproxy/runtime/ssl_certs/ssl%2Fcerts%2Fapi.crt" | jq
{
  "algorithm": "RSA2048",
  "issuers": "/C=xx/ST=xx/L=xxxxx/O=Magic Provisioning/OU=CI/CN=api.glb",
  "not_after": "xxxx",
  "not_before": "xxx",
  "serial": "723xxxx48", # <---- Serial present
  "sha1_finger_print": xxxxx,
  "status": "Used",
  "storage_name": "ssl/certs/api.crt",
  "subject": "/C=xx/ST=xx/L=xxxxx/O=Magic Provisioning/OU=CI/CN=api.glb"
}

❯ curl -s --user xxx:xxx "http://127.0.0.1:xxxx/v3/services/haproxy/storage/ssl_certificates/api.crt" | jq
{
  "description": "managed SSL file",
  "domains": "api.example",
  "file": "ssl/certs/api.crt",
  "issuers": "api.example",
  "not_after": "xxxx",
  "not_before": "xxxx",
  "size": 2940,
  "storage_name": "api.crt"
}

[oliwer]

Hi! Your certificate is probably fine. These 2 APIs (runtime and storage) do not return the same data.

• The runtime API will return all the details about the certificate as returned by HAProxy.
• The storage API was designed to only return "a short summary" of a certificate. This is done in parseCertificate() and it only gathers dates, issuers and DNS names (aka. domains) but not the serial number. This was designed to populate Fusion's UI if I recall correctly.

We use the same struct in both APIs to avoid discrepancies, but we should probably document the difference somewhere. Or maybe provide a new storage API endpoint which returns all the details? But in that case, the result will still be slightly different from the runtime API since the parsing is done differently.

Adding the Serial number to the Storage API output is also possible, although I am unsure what would happen when parsing a file containing multiple certificates (bundle).

[robschn]

@oliwer Oh nice! So the two calls are intentionally different, that's good to know!

What's the split between client-native and dataplaneapi? The call we are using is GetAllStorageSSLCertificates() from the dataplaneapi pkg

We were indexing certs by serial numbers to populate a map, but our self signed certs weren't showing up. It isn't a blocker because we are moving to using the storage_name field regardless, I just wanted to make sure there wasn't a bug somewhere.

[jmdelafe]

👋 @oliwer. Thank you for looking at this.

It's worth mentioning that Storage API does return the Serial as part of the summary when not using a self-signed certificate. Although, as you pointed out, it's not done in the parseCertificate() function.

It's done as part of the ParseCertificatesInfo() function. findLeafCertificate() returns a certificate (and no error) when the issuer is not found in the bundle (not the case for self-signed), and that certificate is used to fill out other data (including ci.Serial) in this logic.

We use this functionality to make sure both certificate loaded (Runtime API) and on-disk (Storage API) matches.

[oliwer]

@jmdelafe you're right, I missed that part. So I guess findLeafCertificate() is a bit too simplistic here. An easy way to fix this would be to simply return the first certificate of the bundle when len(bundle) == 1. Would that work for you?

[jmdelafe]

That'll work, @oliwer. Thanks!

[oliwer]

Should be fixed with 277153b