Since the v4.2 release of CloudCenter (CC), the CC platform has adopted Spring X.509 Authentication, which requires the various roles of the CC architecture to communicate via mutual SSL authentication methods. These certificates are component-based and are different than the client-based certificate described in this article. For a summarized explanation of the differences between the two types and instructions to obtain custom certificates to use for SSL authentication, refer to this article. During the communication between the CloudCenter Manager, the Orchestrator, the Guacamole server, etc., the CloudCenter appliances request a valid certificate from each other as part of the SSL handshake. Once the certificate is offered it will be verified to ensure that it has been signed by a trusted authority. Each CloudCenter deployment needs a unique CloudCenter ID (CCID). The CloudCenter support team uses a known private Certificate Authority (CA) to generate the default certificates, which contain the values for the CCID; it can also be used to generate custom certificates for your deployments upon request. There is an option to request Certificate Signing Request (CSR) files from the CloudCenter support team so that your private CA can generate custom certificates. These component certificates (*.crt) files are stored on each appliance in the /usr/local/tomcat/conf/ssl directory and are specifically named mgmtserver.crt (CCM), cco.crt (CCO), gateway.crt (Docker container), monitor.crt (Health Monitor), guac.crt (Guacamole), and esb.crt (ESB). The goal of this document is to demonstrate how custom certificates can be used in place of the default certificates employed by the CC platform.
NOTE: Assuming that you have a valid certificate signed by a trusted authority, either private or public, you can use one certificate and rename it appropriately to befit to the server role. So a custom.crt file can be renamed to mgmtserver.crt file and placed onto the CCM appliance.
Placing the certificates
On the CloudCenter Manager (CCM)
Replace the default ca_root.crt, ca_truststore.jks, ccm_keystore.jks, ccm.crt, and ccm.key files in the /usr/local/osmosix/ssl/ccm directory
Replace the default ca_root.crt, ca_truststore.jks, esb_keystore.jks, esb.crt, and esb.key files in the /usr/local/osmosix/ssl/esb directory (if ESB is enabled)
Place the ca_root.crt, ca_truststore.jks, esb_keystore.jks, esb.crt, and esb.key files into the /etc/rabbitmq/certs directory (if ESB is enabled)
Ensure that the files are owned by the user named cliqruser
I have deployed an asav on an ec2 instance in aws. When I connect to it there is only 1 interface (management) . Every guide I have read requires me to configure the gig0/0 interface. It doesn't exist. I can't connect via asdm .
Fortunately, Cisco thought about it and made available an ACI simulator for people interested by this technology to simulator a whole ACI environment. This simulator includes Cisco APIC instances with real production software, as its native tools (GUI &am...
Hello Everbody, During my use of Umbrella, which I use to study the traffic of my customers, I was faced with the following information, Cisco does not block (NS, SOA, MX) records/queries, even thought the algorithm considering the domains as 100%(Sc...
We are re-architecting a typical server - agent product for AWS SaaS. The UI and configuration DB will be on the cloud while the agents will be deployed on-prem. The problem is that 100K agents need to periodically poll the server if there are any configu...