Excellent question! The primary use case for using your own CA certificates is for internal compliance, security and governance over your traffic inspection. This means that you can utilize your certificate infrastructure to decrypt and inspect the traffic traversing your environment. As a reminder, TLS inspection is a prerequisite feature for other Cato features, such as RBI, CASB, and DLP.
There are two main approaches to using TLS inspection with your own CA certificates:
-
Upload your own CA certificate with the CA private key
-
Certificate Signing Request from Cato (Customer signed certificate)
The option to use the Cato provided certificate for TLS inspection is always available as well. You can read more about that option here.
It is important to note that you can create multiple certificates, but only one certificate can be active at any given time.
In addition to enhancing the overall security posture of the customer environment, once configured, the custom certificate will be used for TLS inspection on the following rules:
-
Firewall
-
Anti-malware
-
IPS
-
CASB/DLP
-
RBI
With TLS inspection enabled with one of these methods, all TLS traffic will be decrypted for inspection except for traffic that is bypassed using rules.
For the option of using an existing enterprise CA certificate for TLS inspection, first, you will want to upload that signed certificate along with the unencrypted private key.
When the CA certificate is uploaded, you will be presented with a detailed view of the certificate, including the signed CA's name, certificate chain, and expiration date.
If you need to upload a new certificate to update the validity period of the certificate, you can remove the current uploaded files, and start the process again with a new certificate and key pair. The Cato Management Application will start alerting administrators 60 days before certificate expiration both on the Cato Management Application and with an email notification (and repeat at 30 days, 7 days, and the day of expiry) to avoid any inconvenience and lapse of security with an expired certificate.
Certificates that are less than 60 days of validity will have an orange triangle icon beside the Activate button. When you hover your cursor over it, it will display "Certificate is about to expire in XX days". Once the certificate has expired, there will be a red circle icon beside the Activate button, and it will display "Certificate expired" when hover your cursor over the icon, and the Activate button will be greyed out.
Note
Note: Cato is currently unable to revoke certificates.
To upload an existing custom certificate:
-
From the navigation menu, click Security > Certificate Management.
-
Click New, and then select Custom Certificate
-
In the Custom Certificate panel, browse and upload both the custom certificate and the private key for the certificate. After both of those files have been uploaded successfully, click Submit.
After you click Submit, the certificate and key are validated to ensure all of the required information is correct and ready to be used. The uploaded certificate and key will be validated for:
-
The certificate must be an intermediate or CA publisher certificate (the certificate must be able to sign other certificates)
-
The certificate chain exists and includes the root CA
-
Certificate file must be in PEM format
-
Key file is not password protected and minimum encryption key length is 2048 bits in RSA format
-
Private key must match the uploaded CA certificate
If any of these validations fail, an error will be displayed.
-
Using that certificate key pair, Cato will generate a new key pair, then the custom intermediate certificate. The newly created key pair will be signed using the imported private key and be encrypted and stored in the Cato key store. After the new intermediate certificate is generated, the uploaded unencrypted key will be deleted from the system and only the newly generated intermediate certificate will be used.
This option will allow you to generate a Certificate Signing Request (CSR) from your Cato tenant, and then signed by any intermediate certificate that is signed by the organization’s CA. This option, while also increasing the security posture of an environment makes it easier for administrators to create the necessary certificates since the CSR will be generated by the platform that will be using them.
Note
Note: While many CSRs can be generated, only one certificate can be activated at a time per account.
To generate a custom CSR for your account:
-
From the navigation menu, click Security > Certificate Management.
-
Click New , and then select CSR - Certificate Signing Request.
The Create CSR panel appears.
-
Fill in the following required fields:
-
Certificate Name
-
Organization Name
-
Common Name
Note: While other fields of the CSR are optional, it is best practice to fill in all information.
-
-
Click Create CSR to generate the CSR to be signed by your certificate authority.
After you generate the CSR, you will have an option presented to upload the signed certificate.
-
The completed CSR will automatically be downloaded to the administrator's local machine, where you can submit the CSR file to your certificate authority for signing.
-
The signed certificate from the CA will need to be uploaded to the Cato Management Application. Return to the Certificate Management menu and click Upload Certificate.
-
Select the signed certificate from your local machine to upload to the Cato environment, which will enable the certificate to be used for TLS inspection rules.
NOTE: The signed certificate must include the following:
-
Signed by either of the following RSA algorithms:
-
Sha256WithRSAEncryption
-
Sha512WithRSAEncryption
-
-
Signed with minimum key size of 2048
-
Needs to include the following attributes:
-
authorityKeyIdentifier=keyid,issuer
-
basicConstraints=CA:TRUE
-
keyUsage = keyCertSign,cRLSign
Attributes can be confirmed using the following command:
openssl x509 -in signed_cert.crt -text -noout
NOTE: Certificate revocation is not supported at this time.
-
No events are generated for expired certificates, however, audit log entries are created when certificates are generated, uploaded, or removed. Search using "tls account" under Audit Trail > Search field, and it will show the audit trail of the Created and Deleted certificates:
When a custom certificate is working, the browser shows the returned certificate is the same as the custom certificate which was uploaded by the customer to 'Certificate Management' in the Cato Management Application. You can then compare the common name and the certificate fingerprint of the returned certificate with the active certificate in the Cato Management Application.
Here are some useful OpenSSL commands that may help when working with certificates:
-
Checking the private key length using OpenSSL:
-
openssl rsa -in myCA.key -text -noout
-
-
Validating the CA and private keys:
-
openssl x509 -noout -modulus -in cert.crt | openssl md5 -
openssl rsa -noout -modulus -in privkey.txt | openssl md5
Where:
-
cert.crt is your certificate
-
privkey.txt is your private key
Compare the output from both commands. If they are identical then the private key matches the certificate.
-
-
Signing the certificate using OpenSSL:
-
openssl x509 -req -sha256 -CA myCA.pem -CAkey myCA.key -in test\ request.csr -out signed_cert.crt -days 365 -CAcreateserial -extfile signed_cert_attributes.conf
Where:
-
sha256 is the signature algorithm. In mac default is sha-1 . You can use sha512 as well.
-
myCA.pem is your CA
-
myCA.key is your private key
-
request.csr is the csr file you got from cc2
-
signed_cert.crt is your new signed certificate
-
The signed_cert_attributes.conf file has the following example content:
-
basicConstraints=CA:TRUE -
authorityKeyIdentifier=keyid,issuer -
keyUsage = keyCertSign,cRLSign
-
-
0 comments
Article is closed for comments.