You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: