You might have added a device of an unsupported type or operating system version.
Verify the device type and operating system version by logging into the device directly. Verify that you entered the IP address for the right device.
This error is usually caught when you are trying to add the device. You might also see the error if you reassign the IP address from a supported device to an unsupported device. If this is the case, delete the device from the inventory.
User authentication error, invalid username, password
The username or password for logging into the device was rejected by the device.
If this happens while you are adding the device to the inventory, simply correct the username and password. Log directly into the device (for example, using SSH) to verify that the username/password works.
If this happens after you have added the device, and have been successfully managing it, then you probably changed the password for the user that you identified when adding the device. Changing the password (or username) is not allowed. You must delete the device from the inventory and add it back to update the username or password.
On the ASA, keep in mind that the device uses the enable password as the default password for the HTTP server if there is no user password.
Certificate is invalid, certificate out of date, refresh certificate, HTTPS (SSL) error, cannot negotiate SSL, communication error
Secure SSL (HTTPS) communications could not be established. SSL is always used for device communications.
If this occurs when adding a device, first verify that you specified the correct port number used for SSL communications with the device, and that the HTTP server is enabled on the ASA.
If the problem is an invalid certificate, the certificate has either expired, the start date of its valid period is in the future compared to the PRSM server’s current time, or the certificate does not allow both client and server authentication. If the certificate is expired, log into the device and generate a new certificate. If the problem relates to time, correct the time settings on the system that has inaccurate time. Consider using NTP to maintain consistent time for all systems that you are managing with the server.
If the problem is an out of date certificate, or you get a message saying you need to refresh the certificate, go to the inventory list, select the device, and use the Refresh Certificate command.
If the problem is not the certificate, verify that the HTTP server is enabled on the ASA and that you did not change the SSL port after adding the device to the inventory. If you changed the port for SSL, you can change it back to the one identified in the inventory; otherwise, you must delete the device from the inventory and add it back using the new port number.
Finally, SSL communications can fail if there is a time mismatch between the systems. For example, if the validity period for the device certificate is outside the current time of the server. Best practice is to use NTP for all systems to ensure time synchronization.
PRSM certificate is invalid
This error means that there is a problem with the certificate on the PRSM server itself. Device discovery and deployment will not work until you correct the problem. The certificate might be expired, there might be timing issues between the time settings on the server and the managed devices, or the certificate does not allow for both client and server authentication. Ensure that your time settings are good, and obtain a new server certificate. To upload the certificate, select .
Unresponsive device, cannot connect to host, device is unavailable, deployment timed out, communication error
There might not be a route between the server and the device. It is also possible that you changed the IP address or host name for the device in the device configuration, or that you changed the port number for SSL communications. Additionally, there might be firewall rules denying traffic between the devices.
You cannot manage two CX devices that have the same non-default name in the same PRSM server. Discovery can time out due to certificate verification errors because the certificate subject will be the same for the identically-named devices. Ensure you give each CX device a unique name if you do not want to use the default.
Check network connectivity. Keep in mind that the issue is the network connection between the device and the server; you might be able to connect to both from your workstation even when those devices cannot connect to each other. Try logging into the CLI on both systems and using ping or traceroute to check connectivity.
If there is a route, ensure that the HTTP server is enabled on the ASA.
If there is a route between the device and the server, and you changed the IP address, host name, or SSL port number, you need to delete the device from the inventory and add it back using the new addressing information.
If these actions do not resolve the problem, check the access rules on all firewall-capable network devices that are on the path between PRSM and the device; for CX devices, this includes the device in which it resides. Ensure that the existing rules allow HTTPS traffic on port 443 to go between the hosts; you need two allow rules, one where PRSM is the source, one where the unavailable device is the source. If you configured a different HTTPS port than 443, you must allow the port you configured. Ensure that all hops in the network path have the required access rules to allow communication.