There are several steps to establish secure connectivity for each Verato client. Some steps are the responsibility of Verato, and some are the responsibility of the client.
Verato is responsible for the following:
- Verato provisions a user account (with username and strong password) for the client and securely communicate the username and password to the client upon project startup.
- Verato generates a client certificate for use in mutual TLS authentication (along with Verato’s existing server certificate). Verato provides the client with a file with *.jks extension for the certificate—this *.jks file is a keystore, containing the private key information for the client key. Verato also has a copy of the public key information for this key, so that we can recognize and trust incoming traffic from clients using this key.
- Verato provides the client the password required to install and access the *.jks file—this is a different password than the password described in step 1 above. This password is securely communicated to the client separate from the *.jks file itself upon project startup.
- Verato adds the client’s IP addresses to the authorized access list, or allowed list, for the Verato Auto-Steward product.
- Verato provides the client with a WSDL file necessary to invoke Auto-Steward web service.
- Verato uses a server-side certificate as well for the mutual TLS authentication. This server-side certificate is signed by a trusted third-party Certificate Authority (CA). Clients should not need a copy of the public portion of our server key as long as the customer’s authority chain includes the trusted CA.
The client is responsible for the following :
- Client provides to Verato the public IP addresses from which web service requests will be made (the IP addresses as seen from Verato’s side of the connection). The list of IP addresses should include both test and production IP addresses that may be used by the client for calling web services. Over the course of a project, we may initially add one or more IP addresses to an allow list for test servers, and then remove those IP addresses later and replace them with the IP addresses for your production servers.
- Client notifies Verato if firewall restrictions are also imposed on the client’s side for outgoing traffic leaving the client’s infrastructure. In these cases, Verato can provide to the client our own IP addresses to which the web service requests will be sent.
- If necessary, client updates the authority chain on their client computers to include Verato’s Certificate Authority (CA), which is GoDaddy. GoDaddy is a very common CA, and most client computers are already set up to trust this CA. If that is not the case, you can update your authority chain (cacerts file) to trust the GoDaddy CA.
- Client performs a simple connectivity test to confirm that connectivity was successful using the provided user credentials and *.jks file. For more information, see Connectivity Testing.