Cisco Security Cloud Control: Network Devices with Generic SSH Access Management

PDF

Cisco Security Cloud Control: Network Devices with Generic SSH Access Management

Troubleshoot Security Cloud Control

Updated: July 11, 2026

Want to summarize with AI?

Log in

Learn how to troubleshoot Security Cloud Control issues, including login failures, access and certificate problems, and object-related errors.

Troubleshooting login failures

Login Fails Because You are Inadvertently Logging in to the Wrong Security Cloud Control Region

Make sure you are logging in to the appropriate Security Cloud Control region. After you log in to https://sign-on.security.cisco.com, you will be given a choice of what region to access.

Troubleshooting Login Failures after Migration

Login to Security Cloud Control Fails Because of Incorrect Username or Password

Solution If you try to log in to Security Cloud Control and you know you are using the correct username and password and your login is failing, or you try the "forgot password" option and cannot recover a viable password, you may have tried to log in without creating a new Cisco Security Cloud Sign On account. You need to sign up for a new Cisco Security Cloud Sign On Account.

Login to the Cisco Security Cloud Sign On Dashboard Succeeds but You Can't Launch Security Cloud Control

Solution You may have created a Cisco Security Cloud Sign On account with a different username than your Security Cloud Control tenant. Contact the Cisco Technical Assistance Center (TAC) to standardize your user information between Security Cloud Control and Cisco Secure Sign-On.

Login Fails Using a Saved Bookmark

Solution You may be attempting to log in using an old bookmark you saved in your browser. The bookmark could be pointing to https://cdo.onelogin.com.

Solution Log in to https://sign-on.security.cisco.com.

  • Solution If you have created your new secure sign-on account, click the Security Cloud Control tile on the dashboard that corresponds to the region in which your tenant was created:

    • Solution Security Cloud Control APJ

    • Solution Security Cloud Control Australia

    • Solution Security Cloud Control EU

    • Solution Security Cloud Control India

    • Solution Security Cloud Control US

  • Solution Update your bookmark to point to https://sign-on.security.cisco.com.

Troubleshooting Access and Certificates

Resolve New Fingerprint Detected State

Procedure

1.

In the left pane, click Security Devices.
2.

Click the Devices tab.
3.

Click the appropriate device type tab.
4.

Select the device in the New Fingerprint Detected state.
5.

Click Review Fingerprint in the New Fingerprint Detected pane.
6.

When prompted to review and accept the fingerprint:

  1. Click Download Fingerprint and review it.

  2. If you are satisfied with the fingerprint, click Accept. If you are not, click Cancel.
7.

After you resolve the new fingerprint issue, the connectivity state of the device may show Online and the Configuration Status may show "Not Synced" or "Conflict Detected." Review Resolve Configuration Conflicts to review and resolve configuration differences between Security Cloud Control and the device.

Troubleshooting network problems using Security and Analytics Logging events

Here is a basic framework you can use to troubleshoot network problems using the Events Viewer.

This scenario assumes that your network operations team has had a report that a user can't access a resource on the network. Based on the user reporting the issue and their location, the network operations team has a reasonable idea of which firewall controls their access to resources.

Note

This scenario also assumes that an FDM-managed device is the firewall managing the network traffic. Security Analytics and Logging does not collect logging information from other device types.

Procedure

1.

In the left pane, click Events & Logs > Events > Event Logging.
2.

Click the Historical tab.
3.

Start filtering events by Time Range. By default, the Historical tab shows the last hour of events. If that is the correct time range, enter the current date and time as the End time. If that is not the correct time range, enter a start and end time encompassing the time of the reported issue.
4.

Enter the IP address of the firewall that you suspect is controlling the user's access in the Sensor ID field. If it could be more than one firewall, filter events using attribute:value pairs in the search bar. Make two entries and combine them with an OR statement. For example: SensorID:192.168.10.2 OR SensorID:192.168.20.2.
5.

Enter the user's IP address in the Source IP field in the Events filter bar.
6.

If the user can't access a resource, try entering that resource's IP address in the Destination IP field.
7.

Expand the events in the results and look at their details. Here are some details to look at:

  • AC_RuleAction - The action taken (Allow, Trust, Block) when the rule was triggered.

  • FirewallPolicy - The policy in which the rule that triggered the event resides.

  • FirewallRule - The name of the rule that triggered the event. If the value is Default Action then it was the default action of the policy that triggered the event and not one of the rules in the policy.

  • UserName - The user associated with the initiator IP address. The Initiator IP address is the same as the Source IP address.

8.

If the rule action is preventing access, look at the FirewallRule and FirewallPolicy fields to identify the rule in the policy that is blocking access.

Troubleshooting SSL Decryption Issues

Handling Web Sites Where Decrypt Re-sign Works for a Browser but not an App (SSL or Certificate Authority Pinning)

Some apps for smart phones and other devices use a technique called SSL (or Certificate Authority) pinning. The SSL pinning technique embeds the hash of the original server certificate inside the app itself. As a result, when the app receives the resigned certificate from the Firepower Threat Defense device, the hash validation fails and the connection is aborted.

The primary symptom is that users cannot connect to the web site using the site's app, but they can connect using the web browser, even when using the browser on the same device where the app fails. For example, users cannot use the Facebook iOS or Android app, but they can point Safari or Chrome at [/concept/conbody/section/p/xref {"link-https"}) https://www.facebook.com (xref] and make a successful connection.

Because SSL pinning is specifically used to avoid man-in-the-middle attacks, there is no workaround. You must choose between the following options:

More Details

If a site works in a browser but not in an app on the same device, you are almost certainly looking at an instance of SSL pinning. However, if you want to delve deeper, you can use connection events to identify SSL pinning in addition to the browser test.

There are two ways an app might deal with hash validation failures:

  • Group 1 apps, such as Facebook, send an SSL ALERT Message as soon as it receives the SH, CERT, SHD message from the server. The Alert is usually an "Unknown CA (48)" alert indicating SSL Pinning. A TCP Reset is sent following the Alert message. You should see the following symptoms in the event details:

    • SSL Flow Flags include ALERT_SEEN.

    • SSL Flow Flags do not include APP_DATA_C2S or APP_DATA_S2C.

    • SSL Flow Messages typically are: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.

  • Group 2 apps, such as Dropbox, do not send any alerts. Instead they wait until the handshake is done and then send a TCP Reset. You should see the following symptoms in the event:

    • SSL Flow Flags do not include ALERT_SEEN, APP_DATA_C2S, or APP_DATA_S2C.

    • SSL Flow Messages typically are: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE, CLIENT_KEY_EXCHANGE, CLIENT_CHANGE_CIPHER_SPEC, CLIENT_FINISHED, SERVER_CHANGE_CIPHER_SPEC, SERVER_FINISHED.