Does UCS Platform Emulator 3.1(1e) Support non-default Keyrings?

Does UCS Platform Emulator 3.1(1e) Support non-default Keyrings?

I can create TrustPoint with imported Root CA Certificate, and non-default KeyRing, but when I generate Certificate Request in KeyRing the "text field" which shall show the Certificate Request Base-64 is not there.

So is non-default KeyRing supported, and will UCSPE actually use the certificate generated under a non-defau.t KeyRing to identify itself, e.g. towards UCS Central?

/Jesper

Let me add, that neither the release notes nor the User Guide for UCSPE 3.1(1e) mentions anything about KeyRings or Certificates

Hi Jesper,

I'm following up now on the level of testing that's been done for this case in the 3.1 UCSPE and I will get back to you.

Hi again Jesper,

Here's some more information on key rings and how they are used by Central:

"The answer partially depends on what versions of UCS Manager and UCS Central you are using. In the latest version of UCS Central (1.3 and beyond), third party certificates are used for communication between UCS Central and the Client Browser. The communication between UCS Manager and UCS Central is done with internal, self-signed certificates that are not accessible by the customer. This has reduced the number of certificate errors and issues that customers have seen. In  previous versions of UCS Central, we supported the use of the third party certificates for both client communications and communication between UCS Central and UCS Manager.

• If using 3rd party CA certificate, user needs to create a matching keyring
• Default keyring is used only for a self-signed certificate
• If in doubt, create a new TP with the CA cert and matching keyring in UCS Central
• Deploy the new keyring in UCS Central under the Administration > General > HTTPS tab"

We don't expect behavior differences in the emulator compared to UCSM 3.1, but please let us know of other questions.

David

Great with quick response.

The information that UCS Central and UCS Domain always use self-signed certificates in the communication between them (from UCS Central 1.3+) is new to me and very valuable.

Actually the issue I need to solve is, that I hit bug CSCuu85942 "UCSM domains entered Lost Visibility status after upgrading UCS Central", where the error description states "UCS Central and UCSM are using self-signed certs". So I thought this bug only appeared when UCS Central and UCS Domain used self-signed certificates for their mutual communication, and that I could avoid the bug by using certificates issued by a trusted CA for both UCS Central and UCS Domain.

So now I have learned that UCS Central and UCS Domain always authenticate with self-signed certificates between them, so this raises the following questions:

a. Is it correct that You cannot avoid hitting this bug?

b. The described work around (with reentering the UCS Central shared secret on the UCS Domain through CLI) seems to work. However for practical reasons I have not yet tested, that this work around keeps working after a restart of the UCS Domain. So: When I have registered a new UCS Domain, hit the bug and gone into "lost visibility" state, and then performed the work around in the CLI, and hereafter gone back to "registered" state, what will then happen, if I reboot my UCS Domain: will it keep its "registered" state within UCS Central or will I have to perform the work around yet another time after the reboot?

c. According to the bug description there are no plans to fix this bug? Is that correct? If there plans to fix the bug, then at what point of time? I really think the bug should be fixed, since it will constitute a significant issue in production.

BR

Jesper

Hi again Jesper,

I'm checking on root cause for the issue you mention (CSCuu85942), but I do see that issue is considered "resolved" in Central 1.3 and beyond.  Are you able to try 1.3 or later versions to confirm you no longer see the issue on your systems?

Also, what version of UCS Central did you upgrade from.....to ?

Registration Cert-Exchange (with Default Self-signed UCSM Cert) only occurs once upon the initial UCSM Registration with UCSC.

David, Mfaiello

I am using a fresh install (no upgrade) of UCS Central 1.5(1a), and consistently get the error both with UCSPE 3.1(1e) and physical UCS Domain 2.2(6g)

Can you please open a TAC Case, and upload a Show-tech? There has to be something unique about your environment.

Thanks,

Matt

David, Mfaiello

Will initially redo my test just to be sure, and then open TAC case, will keep You informed

BR

Jesper

Thank you…please do.

Best Regards,

Matt

Matthew Faiello | UCS Technical Marketing Engineer | .:|:.:|:. Cisco Systems, Inc.

mfaiello@cisco.com<mailto:mfaiello@cisco.com>| Phone: 727-540-1432 | Twitter: @mfaiello

UCS Communities: http://communities.cisco.com/ucs

UCS Platform Emulator:  http://communities.cisco.com/ucspe

UCS Developed Integrations:  http://communities.cisco.com/ucsintegrations

Matt, David

Can only recreate the error on UCSPE 3.1(1e). Have done the following:

1. New UCS Central 1.5(1a) VM, only config is NTP server

2. Registered one physical UCS Domain 2.2(6c) and 6 UCSPE 3.1(1e) Domains

3. They stay "registered" all of them for several hours (during my testing they normally went into lost-visibility after approx. 20 min).

4. Configured UCS Central with DG hierarchy and assigned the Domains to specific DGs, and a lot of other configuration. All of which to the best of my belief is "legal"

5. All the UCSPE's go into "lost-visibility" after approx. 20 min. Physical UCS Domain remains registered. I perform CLI based workaround with resetting the UCS Central shared secret on one of the UCSPEs, it goes "registered"

6. More than 12 hours later the physical UCS Domain and the one "work around'ed" UCSPE remain registered, all other UCSPEs remain in "lost-visibility"

I remembered it as if I had had the error also on physical UCS Domain, but can see, that I have not been able to recreate it there so far.

The UCSPE is delivered "as is", so I assume, that I cannot open a TAC Case on the error with the UCSPE.

Does the fact, that the error occurs on the UCSPE 3.1(1e), matching both the symptom and the work around of CSCuu85942, and not on physical UCS Domain (2.2(6c)), make sense to You. Can You give an explanation of that?

I assume, that I can trust that the error will not occur towards UCS Central 1.5(1a) on physical UCS Domains 2.2(6)+, however I will keep an eye on that on my future testing (right now I have limited access to physical UCS Domains for testing).

Will the BU be interested in troubleshooting the error on UCSPE 3.1(1e) (I can provide diagnostics)? If so it could be clarified, if there still exist issues in the UCSM software 3.1(1e)+.

I propose, that You update the description and status of CSCuu85942, such that it is clear, that the issue is fixed in UCS Central 1.3+. I focused a lot on that bug, since it matched the errors I get with UCSPE 3.1(1e) perfectly both with respect to symptom and workaround.

BR

Jesper

Hi again Jesper,

We have found that there are some differences in how the Platform Emulator handles key rings compared to HW based UCSM.  We will let you know once we have root cause and if there is a possible fix.  Until then, the work-around for CSCuu85942 is the best option for the issue on the Emulator.

I have updated the CDET with the following text in the work-around field:

"Upgrading to UCS Central 1.3 and later resolves the issue (issue has not been reported on HW with 1.3 and later).  For releases prior to 1.3 or if the issue is observed with the UCS Platform Emulator, perform the work-around below.

On UCS FI that is in "Lost Visbility " status, enter a dummy shared secret and then the correct shared secret.

scope system

scope control-ep policy

set shared secret <wrong-value>

commit-buffer

set shared secret <original-correct-value>

commit-buffer”

Let us know of any other questions.

David

I have got the information I need with respect of impact of bug CSCuu85942 on physical UCS and UCS Platform Emulator, and Your update of the bug description clearly reflects its state.

I will look forward to Your update, when it is there, about the root cause to the differences between UCS Platform Emulator and UCSM on Physical UCS for key-rings.

I will mark Your reply as "correct" and "close" the case in this way.

BR

Jesper