Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate Apostille techniques in Mallet to clone certificates #5

Open
RoganDawes opened this issue May 7, 2019 · 1 comment
Open

Comments

@RoganDawes
Copy link
Collaborator

RoganDawes commented May 7, 2019

It should be possible to preemptively make a connection to the upstream target to obtain a copy of the certificate, and copy the major properties from that certificate into our own when intercepting. For example, dates, serial numbers, algorithms and key sizes, etc could all be used to make the certificate as similar as possible to the original.

This could be a configurable thing, with options being to "use an existing key from the keystore if one exists", "retrieve and copy from target", "just make one up" (current behaviour).

So, certificate handling would generally be:

  • If a certificate exists in the keystore, always use that.
  • If configured to fetch and clone, there would be two possibilities:
    • Fetch and clone the entire chain, including the CA (assuming it is available in the Java Trust Store). This is what Apostille does. Users would need to update the trust store on the client with the new CA certificate, for each cloned CA. Mallet should save cloned CA certificates into the keystore for repeated use.
    • Fetch and clone the entire chain, except for the CA. Use the Mallet custom CA instead.
  • Create the certificate simply based on the requested CN, and cache in memory, but don't save it in the keystore.

Allow configuration of whether to discard generated leaf certificates or not. These would be discarded on exit, and will need to be regenerated the next time Mallet is run, or can be saved persistently. Persistent leaf certificates can be a problem if the cert has a short lifetime, as Mallet would not generate a new certificate due to finding one in the keystore.

Mallet could check expiry dates, but that would eliminate the possibility of testing behaviour of clients when faced with an expired cert! Perhaps best to simply log a warning somewhere. That said, the client should trigger an error when presented with an expired certificate, so the "operator" should be aware.

It would be necessary to provide a simple interface to allow users to import, export and delete entries from the keystore.

@RoganDawes
Copy link
Collaborator Author

Provide a simple framework interface to retrieve a certificate chain for a target:port, which could make use of framework features such as an upstream proxy, or "hostname:ip address" mappings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant