The Cloud service plays a vital role within the VMS software suite, enhancing the overall functionality and usability of the VMS System. By leveraging the Cloud service, users gain the ability to access their Systems remotely, without the need for complex network configurations. This remote access is available for all Clients that are part of the Software Suite, such as the Desktop Client, Mobile Client, WebAdmin, and Cloud Portal.
When a System is connected to the Cloud, it becomes accessible through the Cloud mediator, a relay service specifically developed and hosted on the Amazon Web Services (AWS) platform. As a result, Clients can easily connect and display the connection status, indicating whether the System is Offline, Unreachable, or Online – which is visually represented by a cloud icon.
We believe that utilizing the Cloud service provides our users with a seamless and convenient experience, enabling them to stay connected to their Systems from virtually anywhere.
Why shows a system itself as Offline or Unreachable?
Offline means the System isn’t able to communicate with the Cloud and the System is not available at the moment. It could be due to the server application not running, the Server or Client aren’t connected to the internet.
Unreachable means the System is online and in working state, but unable to be connected via the Client through Cloud due to various reasons and may be solved by simple actions depending on the situation.
Most common connection issues
Firewall Configurations / Network restrictions
We want to highlight that our Cloud service is designed to seamlessly integrate into most general networking environments without requiring any additional configurations. However, in certain, enterprise, network setups, we have observed instances where specific services might be blocked, potentially affecting the smooth operation of the Cloud service due to network restrictions and/or firewalls configurations.
For instance, some companies implement outgoing and incoming connection restrictions to URLs that have not been explicitly granted permission. Consequently, this can prohibit the communication between the System and the Mediator, and/or Relay servers (for more details, you can refer to THIS support article), leading to an inability in the connection between the Servers and the Clients.
We understand the importance of a reliable and uninterrupted service, and we're here to assist you in addressing any challenges you might encounter in your particular networking environment. If you require any guidance or support to ensure a seamless Cloud service experience, please don't hesitate to reach out to our support team. We're committed to providing you with the best possible assistance to overcome any obstacles and make your experience with our Cloud service a positive and productive one.
Script to check and resolve the accessibility
We have a helpful solution to address and verify the concern you've encountered. You can find a Python script at the bottom of THIS support article. This script allows you to check the accessibility of the cloud servers.
By running the script on the server, you will receive detailed connectivity test results for all the required servers which are used by the Cloud service and the VMS system. All connections should pass as OPEN successfully.
In the event that any URLs are found to be blocked in the test results, we recommend reaching out to your networking administrator. They can assist in configuring the firewall to permit the necessary traffic, ensuring smooth and uninterrupted operations.
Self-signed Certificates
In certain network environments, strict network policies are in place. These policies often impose, as mentioned above, limitations on incoming and outgoing traffic, as well as require devices to either reside within the network or use a certified SSL certificate to gain access.
You have the option to incorporate your own validated certificates, following the instructions provided in THIS support article.
By default, the VMS uses self-signed certificates, which can occasionally lead to connectivity issues if the Client is on an external network. In such cases, the System may encounter difficulties in accessing the System.
Additionally, for those who have upgraded their Nx Witness System from an older version (version 4.2 or older), it's essential to be aware that the self-signed certificate might have expired. Consequently, any HTTPS connection attempts may not be established successfully.
Renewal of the self-Signed Certificates
To renew the self-signed certificate, please follow the steps below:
- Stop the Server application
- Navigate to the directory for the Nx Server SSL certificate.
For Windows:C:\Windows\System32\config\systemprofile\AppData\Local<brandName>\<brandName>Media Server\ssl
For Ubuntu:
/opt/<brandName>/mediaserver/var/ssl
- Navigate to the directory for the Nx Server SSL certificate.
- Delete the default.pem to remove the old certificates
- Restart the Server application, and a new certificate with an updated expiration will be created, and from now on, it will be renewed automatically
NOTE: If the issue is not resolved, please try to delete the certificate again and restart the server application once more.
Missing Amazon Root CA 1 certificate
Adding and trusting the Amazon Root CA 1 certificate is typically necessary in scenarios where you interact with Amazon Web Services (AWS) or other applications and services that use certificates issued by Amazon's Certificate Authority (CA). The Amazon Root CA 1 certificate is the root certificate used to sign various SSL/TLS certificates within the AWS ecosystem. Trusting this certificate allows your system or application to verify the authenticity and security of connections made to AWS services or other services that rely on Amazon-issued certificates.
How to install the Amazon Root CA 1 certificate?
For Windows
- Obtain the certificate: Download the Amazon Root CA 1 certificate from the official AWS documentation or from the Amazon Trust Services website. Save the certificate file with a .cer extension.
- Open the Certificate Manager: Press the Windows key + R to open the Run dialog. Type certmgr.msc and press Enter. This will open the Certificate Manager.
- Import the certificate: In the Certificate Manager, navigate to Trusted Root Certification Authorities" > Certificates.
Right-click on the Certificates folder and choose All Tasks > Import. - Browse to the certificate file: Follow the import wizard, click Next, and then browse to the location where you saved the Amazon Root CA 1 certificate file. Select the file and click Next.
- Choose the certificate store: Choose Place all certificates in the following store and click Browse and select Trusted Root Certification Authorities and click OK and Next.
- Complete the import: Review the import settings and select Finish to complete the process. If you see any security warnings during the import, you can safely proceed, as long as you obtained the certificate from a trusted source.
- Verify the installation: Open the Certificate Manager and navigate to Trusted Root Certification Authorities > Certificates. Look for the Amazon Root CA 1 certificate in the list.
For macOS
- Obtain the certificate: Download the Amazon Root CA 1 certificate from the official AWS documentation or from the Amazon Trust Services website. Save the certificate file with a .cer extension.
- Open Keychain Access: You can find Keychain Access in the Utilities folder, which is within the Applications folder. Alternatively, you can use Spotlight search (Cmd + Space) and type Keychain Access to find and open it.
- Import the certificate: In the Keychain Access application, navigate to File > Import Items or use the shortcut Cmd + Shift + I.
- Locate the certificate file: Select the Amazon Root CA 1 certificate file you downloaded, and select Open to import it into the Keychain.
- Choose the keychain to add the certificate: Keychain Access will ask you to choose the keychain where you want to store the certificate. You can usually select System to make it available system-wide. If you want the certificate to be available only for your user account, select Login.
- Provide administrative privileges: To add the certificate, you'll need to provide administrative credentials (username and password) for your device.
- Verify the installation: Once the certificate is imported, it should appear in the Keychain list with the name Amazon Root CA 1 or a similar identifier.
- Set the trust settings (if necessary): Depending on your use case, you might need to modify the trust settings for the certificate. To do this:
- Double-click on the certificate in the Keychain list to open the certificate details.
- Expand the Trust section and adjust the settings as required.
- For most scenarios, you can set When using this certificate to Always Trust to ensure all applications trust connections signed by this certificate.
For Ubuntu Linux
- Obtain the certificate: Download the Amazon Root CA 1 certificate from the official AWS documentation or from the Amazon Trust Services website. Save the certificate file with a .cer extension.
- Copy the certificate to the appropriate directory: Open a terminal and copy the certificate file to the certificates directory using the sudo command.
For example:sudo cp /path/to/amazonRootCA1.cer /usr/local/share/ca-certificates/
- Update the certificate store: After copying the certificate, update the system's certificate store using the update-ca-certificates command:
sudo update-ca-certificates
This command will scan the /usr/local/share/ca-certificates/ directory for certificates and update the certificate store accordingly.
- Verify the installation: You can check if the certificate was successfully added by looking for the certificate file's name in the /etc/ssl/certs/ca-certificates.cet file. You can also use the grep command to search for the certificate's subject line as follows:
grep "Amazon Root CA 1" /etc/ssl/certs/ca-certificates.cet
If the certificate was added correctly, you should see the subject line printed in the terminal.
Comments
0 comments
Article is closed for comments.