The client certificate holding tank holds certificates that have been presented by a user as authentication credentials but have not yet been accepted as valid credentials for that user. The holding tank is populated automatically whenever an SSL connection is established and a valid username is presented along with an invalid certificate. Holding tank entries will NOT be created if an SSL connection could not be established due to client cert trust issues.
The use of a holding tank in cert authentication situations makes it easy for administrators to accept specific certs for users without having to manually add, import, or create certificates into a user profile.
The following procedure describes how an FTP/SSL client can connect with a new cert and leave the cert's fingerprint behind for an administrator to promote/accept into the user's profile at a later date. Any FTP/SSL user whose client has already installed an SSL client cert signed by a CA registered in MOVEit DMZ's Microsoft Trusted Root Certificate store should be able to use this procedure.
First, have the remote FTP/SSL client attempt to connect to MOVEit DMZ. This connection should fail. For example, the following MOVEit Freely session attempts to connect with a client key and fails.
C:\>ftps -ccn:lucy -e:on -a -user:moveitfreelydemo -password:a1s2d3 dotnet 220-Security Notice 220-You are about to access a secured resource. Ext Auth Mania reserves the 220 right to monitor and/or limit access to this resource at any time. 234 SSL enabled start the negotiation Connected to dotnet. 530 Not logged in. Client Certificate is not registered. ftp> quit 221 Goodbye
Next, sign on as an Admin to MOVEit DMZ and go to the client cert administration page of the user who just tried to authenticate. The second section on this page displays the Holding Tank entries for this user.
Notice that a single authentication attempt put TWO entries into the holding tank: one for the CN of the cert, and one for the thumbprint. Either may be accepted by clicking the Accept link for that entry.
If you accept the cert CN, you will avoid cert renewal issues if the end user gets an updated cert with the same CN but a different expiration date. However, you also run a risk of CN collision if any of this organization's Trusted CAs issue CNs with the same name to multiple people (e.g., Thawte Free Email certificates) or you have multiple trusted CA's.
If you accept the Thumbprint of the cert, you will encounter cert renewal issues if the end user gets an updated cert with the same CN but a different expiration date. However, you will avoid the risk of CN collision if any of this organization's Trusted CAs issue CNs with the same name to multiple people (e.g., Thawte Free Email certificates) or you have multiple trusted CA's.
As a rule of thumb, if you use a limited number of org-level Trusted CAs (e.g., your organization is its own CA), you should probably choose to accept CN's. If you use many Trusted CAs or you include CAs which issue certificates with the same CN to multiple people, you should probably choose to accept thumbprints. (Authentications using client cert thumbprints do not pay any attention to the list of Trusted CAs.)
In our example, we will accept the "SSL CN" of the client certificate because it was issued by a CA which never issues certificates with the same CN to different people.
After either the CN or Thumbprint is accepted, a confirmation screen will appear which contains several interesting pieces of information and a question. On the top of the page, there is a success message and a short display showing the accepted value (the CN, in this case). The question at the bottom of the page asks if you would like to get rid of the other holding tank entry the certificate created. You will usually want to click the "DELETE" option, but you could, technically, add both the CN and Thumbprint to a user record. (If you did this, the user would still only need to provide a cert with the correct CN or the correct Thumbprint - not both.)
After electing to either delete or keep the other holding tank entries, you will be returned to the client cert administration page, where the newly accepted entry should now be present. At this point, it is time to try the FTP client sign on again.
C:\>ftps -ccn:lucy -e:on -a -user:moveitfreelydemo -password:a1s2d3 dotnet 220-Security Notice 220-You are about to access a secured resource. Ext Auth Mania reserves the 220 right to monitor and/or limit access to this resource at any time. 234 SSL enabled start the negotiation Connected to dotnet. 331 Password required for moveitfreelydemo 230-Welcome to JGL Test Org. Enjoy your stay & have fun! 230 User moveitfreelydemo logged in. 200 PBSZ command successful 200 PROT command successful 215 Windows_NT version 5.0 (MOVEit DMZ FTP 3.1.8.6) 200 Integrity mode selected ftp>
This time the sign on attempt worked.
A complete list of all unassigned certs for all users in the organization may be viewed in the organization-wide holding tank. The organization-wide holding tank is accessible from the "Settings" page by following either the "Security | Interface Policy | FTP" or "Security | Interface Policy | HTTP" links. To assign specific certs, click into the complete list with the "View Tank Keys" link.
Cert information is listed by username and then by type. Select the appropriate cert and click the "Accept" link next to it. After a cert has been accepted, the interface will return to the organization-wide holding tank so other keys may be assigned or deleted.
Unassigned certs will automatically be cleaned out the holding tank after a certain number of days. The exact number of days is a configurable option under the organization-wide SSL policy. (The same value applies to unassigned SSH client keys and untrusted CA certs in the holding tank.)
Unassigned certs may also be manually cleaned out an individual user's holding tank or the organization-wide holding tank using any of the provided "delete" or "delete all" links.