[EDIT 20170227: The process for configuring third party certificates for EM13c works about the same as for EM12c. If you have access to Oracle support, I suggest you review notes 2220788.1 and 2213661.1 for the most up-to-date documentation directly from Oracle.]
By default, when an administrator configures Oracle Enterprise Manager 12c to use SSL, the system will use a default self-signed certificate, provided for demo purposes only. The documentation states repeatedly that users should not use these certificates in a production environment, as they represent a security risk. This blog post documents, step by step, a process to replace these demo certificates with custom third party certificates, across the OMS console, OMS upload port, agents, and WebLogic Server. I will follow this process on a single-OMS configuration; if you have more than one OMS please consult the documentation for more details, as your process will vary and the steps I have provided may break your system.
I have tested these instructions on Linux x86-64 (SLES11 SP3) with EM12c R4 PSU2 (12.1.0.4).
Official Documentation
The official documentation for this process resides in the following My Oracle Support notes:
- Using ORAPKI Utility to Create a Wallet with Third Party Trusted Certificate and Import into OMS (Doc ID 1367988.1)
- EM 12c Cloud Control How to Create a Wallet With Third Party Trusted Certificate that Can Be Imported into the OMS For SSL Comunication ? (Doc ID 1399293.1)
- 12c Cloud Control: Steps to Import Third Party Trusted SSL Certificate into 12c Cloud Control Agent URL (Doc ID 1593183.1)
- 12c Cloud Control: Steps to Create and Import Third Party / Self-Signed SSL Certificates for WebLogic Server in an Enterprise Manager Installation (Doc ID 1527874.1)
- How to Create a Java Keystore via Keytool in FMW 11g/12c (Doc ID 1230333.1)
Why Should I Do This?
You may not fully understand the mechanics of SSL/TLS certificates and the chain of trust. I cannot fully explain this complex topic in a blog post, but if you need a reason to make this change other than demands from your organizational security/compliance team, please take Oracle’s word for it, and notice the text that appears in your GCDomain.log file when you run your system with the provided default demo certificates.
Read that again if you didn’t catch it the first time through: “The system is vulnerable to security attacks, since it trusts certificates signed by the demo trusted CA.” This text comes from code in WebLogic, not from me. Here Oracle tells you very explicitly that your system currently contains a severe vulnerability.
You will also notice that when using the EM12c console, or accessing an agent URL, or accessing the WebLogic Server administration console may show warnings in your browser about untrusted certificates. Once you replace your certificates as described in the documentation above or my steps below, you will no longer have those issues.
Using 3rd Party SSL/TLS Certificates With EM12c
Overview
You will follow 7 high level steps to complete the process of securing your EM12c environment with custom third party SSL/TLS certificates.
- Create an Oracle wallet for the OMS.
- Secure the OMS console using the OMS wallet.
- Secure the OMS upload port using the OMS wallet.
- Re-secure all agents.
- Create Oracle wallets for agents.
- Configure the agents to use their wallets.
- Secure WebLogic with the OMS wallet.
Create an Oracle wallet for the OMS
First we follow steps 1a through 1h from document 1367988.1. All these steps occur on the OMS host.
Disable shell history (optional but recommended)
While following these steps, you will repeatedly have to type passphrases on the command line. To avoid having these passphrases stored in your Oracle user’s shell history, disable history saving. In the bash shell that I use, I accomplish this by unsetting the HISTFILE variable. You may need to use another mechanism in another shell.
$ unset HISTFILE
Use the correct ORAPKI command
You should use the ORAPKI command from your middleware home’s oracle_common/bin directory. I will refer to this as $MW_HOME/oracle_common/bin/orapki in the following instructions.
Create an Oracle wallet
The documentation specified that we should create an auto-login wallet, but in my single-OMS setup, I believe that I will achieve better security with an auto-login-local wallet, as the auto-login feature will only function on this specific host. You will need to select a base directory for your OMS wallet. I used $ORACLE_BASE/oemwallet. ORAPKI will prompt you for a password. Use a secure one, and note it down somewhere safe. You will use it many times during this process.
$ mkdir $ORACLE_BASE/oemwallet $ $MW_HOME/oracle_common/bin/orapki wallet create -wallet $ORACLE_BASE/oemwallet -auto_login_local Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Enter password: Enter password again:
Get in the habit of displaying the wallet contents after each operation to confirm that everything worked.
$ $MW_HOME/oracle_common/bin/orapki wallet display -wallet $ORACLE_BASE/oemwallet Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Requested Certificates: User Certificates: Trusted Certificates: Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Create a key within the wallet. Make sure you replace omshost.domain.com with the fully qualified domain name of your OMS host. I highly recommend using a 2048 bit keysize, as shown below. Include the wallet password you specified earlier on the commandline as the -pwd argument, contained in single quotes. Display the wallet again afterward.
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -dn "CN=omshost.domain.com,OU=EM,O=Organization,L=City,ST=State,C=US" -keysize 2048 -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet display -wallet $ORACLE_BASE/oemwallet Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Requested Certificates: Subject: CN=omshost.domain.com,OU=EM,O=Organization,L=City,ST=State,C=US User Certificates: Trusted Certificates: Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
Export a certificate signing request based on this key. Make sure the -dn you specify exactly matches the -dn specified earlier. Provide a filename in the -request argument in which to store the certificate signing request (CSR).
$ $MW_HOME/oracle_common/bin/orapki wallet export -wallet $ORACLE_BASE/oemwallet -dn "CN=omshost.domain.com, OU=EM,O=Organization,L=City,ST=State,C=US" -request ~/EM12cCSR.txt Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
Submit this CSR file to your signing authority. Inform them that you MUST have a single-host certificate with your OMS host’s fully qualified domain name in the CN field. Subject Alternate Name (SAN) certificates or wildcard certificates will not work at all. Your signing authority should then provide you with a root certificate, an intermediate certificate, and a user certificate.
Import the root, intermediate, and user certificates into the OMS wallet. Note that you must import the root and intermediate certificates using -trusted_cert, and the user certificate using -user_cert. I used DigiCert, and I can confirm that their certificates function correctly in EM12c and recommend their service.
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -trusted_cert -cert ~/TrustedRoot.cer -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -trusted_cert -cert ~/DigiCertCA2.cer -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -user_cert -cert ~/omshost.domain.com.cer -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
Display the wallet contents after this operation.
$ $MW_HOME/oracle_common/bin/orapki wallet display -wallet $ORACLE_BASE/oemwallet Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Requested Certificates: User Certificates: Subject: CN=omshost.domain.com,OU=[REDACTED],O=[REDACTED],L=City,ST=State,C=US Trusted Certificates: Subject: CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US Subject: CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Concatenate the root and intermediate certificates into a single file, which you will use later.
$ cat ~/DigiCertCA2.cer ~/TrustedRoot.cer > $ORACLE_BASE/trusted_certs.txt
You have completed configuration of your OMS wallet.
Secure the OMS console
Now, using emctl from the $OMS_HOME, tell EM12c to secure the OMS console using the certificate contained in your wallet. The system will prompt you for the SYSMAN password and inform you to restart the entire OMS once complete.
$ $OMS_HOME/bin/emctl secure console -wallet /oracle/oem/oemwallet Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Securing Console... Started. Enter Enterprise Manager Root (SYSMAN) Password : Securing Console... Successful Restart OMS $ $OMS_HOME/bin/emctl stop oms -all ; sleep 5 ; $OMS_HOME/bin/emctl start oms
Now access your OMS console with your favorite browser and confirm that your new certificate appears. Your certificate should show a trusted path back to a root certificate, and your browser should produce no warnings.
At this point, you have secured communication between your browser and the EM12c OMS console with your custom certificate. You still have more work to do though. Your agents upload monitoring data to the OMS upload port, and it still uses the demo certificate. Fix that in the next step.
Secure the OMS upload port
Secure the OMS upload port. Expect to receive email or pager alerts after this step, as once you restart the OMS, none of your agents can communicate with it, as they expect to see the demo certificates on the upload port. You will need to provide the SYSMAN password as well as an agent registration password.
$ $OMS_HOME/bin/emctl secure oms -wallet $ORACLE_BASE/oemwallet -trust_certs_loc $ORACLE_BASE/trusted_certs.txt Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Securing OMS... Started. Enter Enterprise Manager Root (SYSMAN) Password : Enter Agent Registration Password : Securing OMS... Successful Restart OMS $ $OMS_HOME/bin/emctl stop oms -all ; sleep 5 ; $OMS_HOME/bin/emctl start oms
Re-secure all agents
Now you must re-secure all of your agents so that they can resume uploading data to the OMS console and monitoring your systems. Execute the following steps on every agent, using emctl from the agent home. You will need to provide an agent registration password to complete this process.
$ $AGENT_HOME/bin/emctl secure agent Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Agent successfully stopped... Done. Securing agent... Started. Enter Agent Registration Password : Agent successfully restarted... Done. Securing agent... Successful. $ $AGENT_HOME/bin/emctl upload agent Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. --------------------------------------------------------------- EMD upload completed successfully
It may take a little while for the OMS to process the new agents and their uploads, but once you have run this process on every agent they should all communicate successfully with the OMS and appear as OK from the agent management screen.
Create Oracle wallets for agents
Next we secure the agent URLs. The OMS connects to the agents at this URL to submit management requests. At the moment, the agents still use self-signed certificates to secure this URL. For this process we create an Oracle wallet, on the OMS host, using the same ORAPKI command as for the OMS wallet. We will generate a certificate signing request from each agent wallet, submit those CSRs to a certificate authority, and import the received certificates.
As with the OMS, the agents must use single-host certificates, not wildcard or subject alternate name (SAN) certificates. To determine the correct fully qualified domain name for each agent, execute emctl status agent from the agent home.
$ $AGENT_HOME/bin/emctl status agent Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. --------------------------------------------------------------- Agent Version : 12.1.0.4.0 OMS Version : 12.1.0.4.0 Protocol Version : 12.1.0.1.0 Agent Home : /oraagent/agent12c/agent_inst Agent Log Directory : /oraagent/agent12c/agent_inst/sysman/log Agent Binaries : /oraagent/agent12c/core/12.1.0.4.0 Agent Process ID : 12480 Parent Process ID : 12359 Agent URL : https://agenthost.domain.com:3872/emd/main/
Repeat these steps for every agent.
Create a directory to store the agent wallet, and an agent wallet. This time do NOT use -auto_login_local, use only -auto_login, as you will distribute these wallets to the agent hosts after generating them on the OMS host. Use a strong password, and save it for later, as you will reuse it many times.
$ mkdir $ORACLE_BASE/agentwallets $ mkdir $ORACLE_BASE/agentwallets/agenthost.domain.com $ $MW_HOME/oracle_common/bin/orapki wallet create -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -auto_login Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Enter password: Enter password again:
Create the certificate, then a certificate signing request, saving it to file ~/agenthost.domain.com.csr. Again, I recommend a 2048 bit certificate.
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -dn "CN=agenthost.domain.com,OU=EM,O=Organization,L=City,ST=State,C=US" -keysize 2048 -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet export -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -dn "CN=agenthost.domain.com,OU=EM,O=Organization,L=City,ST=State,C=US" -request ~/agenthost.domain.com.csr Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
As before, submit this certificate signing request to your certificate authority, and receive back three files containing a root certificate, an intermediate certificate, and a user certificate. Import these into the agent wallet, and display the wallet afterwards to confirm everything imported successfully.
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -trusted_cert -cert ~/TrustedRoot.crt -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -trusted_cert -cert ~/DigiCertCA.crt -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com -user_cert -cert ~/agenthost.domain.com.crt -pwd '[REDACTED]' Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. $ $MW_HOME/oracle_common/bin/orapki wallet display -wallet $ORACLE_BASE/agentwallets/agenthost.domain.com Oracle PKI Tool : Version 11.1.1.7.0 Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved. Requested Certificates: User Certificates: Subject: CN=agenthost.domain.com,OU=EM,O=Organization,L=City,ST=State,C=US Trusted Certificates: Subject: CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US Subject: OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US Subject: CN=DigiCert High Assurance CA-3,OU=www.digicert.com,O=DigiCert Inc,C=US
You have finished creating this agent’s wallet. Repeat this for every agent.
Configure the agents to use their wallets
Inside the agent wallets you’ve just created, you will find a cwallet.sso file. Take this file from each agent’s wallet and copy it to the agent server. Stop the agent, then place the file into $AGENT_INSTANCE_DIR/sysman/config/server/ and set the permissions to 640, then start the agent.
$ $AGENT_HOME/bin/emctl stop agent Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Stopping agent ..... stopped. $ cp cwallet.sso $AGENT_INSTANCE_DIR/sysman/config/server $ chmod 640 $AGENT_INSTANCE_DIR/sysman/config/server $ $AGENT_HOME/bin/emctl start agent Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Starting agent ............. started.
Next, visit the agent URL in your favorite web browser and examine the certificate it uses. You should now see that it uses the 3rd party SSL/TLS certificate that you installed.
Secure WebLogic with the OMS wallet
Now the OMS (both console and upload ports) and agents will use your new certificates. This leaves WebLogic as the one remaining component needing your new certificates. Please note in following the below directions that securing WebLogic with a wallet only works as of EM12c R3, earlier versions must use a Java keystore. See note 1527874.1 for more information.
[NOTE: 20150910: If you secure WebLogic with a certificate that uses the SHA256 hashing algorithm, future attempts to apply EM12c PSU patches using ‘opatchauto’ will fail. Some piece of opatchauto does not support SHA256 usage in certificates. If you run into this issue, revert your WLS to the demonstration certificate using emctl secure wls -use_demo_cert, then apply the PSU, then resecure WLS using these steps with your desired certificate. I intend to write a full blog post about this later.]
First import the root and intermediate certificates to the keystore on the OMS host’s agent. Use the default password welcome for the agent keystore, and alias names rootcacert and intercacert.
$ $AGENT_HOME/bin/emctl secure add_trust_cert_to_jks -trust_certs_loc ~/TrustedRoot. crt -alias rootcacert -password welcome Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Message : Certificate was added to keystore ExitStatus: SUCCESS $ $AGENT_HOME/bin/emctl secure add_trust_cert_to_jks -trust_certs_loc ~/DigiCertCA. crt -alias intercacert -password welcome Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Message : Certificate was added to keystore ExitStatus: SUCCESS
Back up some WLS configuration files, just in case, before securing WLS with your certificate. If you have problems in this step, make sure you have stopped all WLS processes, then restore these files from backup.
$ mkdir ~/wlscertbak $ cp -a $EM_INSTANCE_BASE/em/EMGC_OMS1/emgc.properties ~/wlscertbak/ $ cp -a $EM_INSTANCE_BASE/NodeManager/emnodemanager/nodemanager.properties ~/wlscertbak/ $ cp -a $EM_INSTANCE_BASE/WebTierIH1/config/OHS/ohs1/keystores/proxy ~/wlscertbak/ $ cp -a $EM_INSTANCE_BASE/user_projects/domains/GCDomain/config/config.xml ~/wlscertbak/
Stop the OMS.
$ $OMS_HOME/bin/emctl stop oms Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Stopping WebTier... WebTier Successfully Stopped Stopping Oracle Management Server... Oracle Management Server Successfully Stopped Oracle Management Server is Down
Secure WLS using the OMS wallet created earlier. You will need to provide the SYSMAN password.
$ $OMS_HOME/bin/emctl secure wls -wallet $ORACLE_BASE/oemwallet Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Securing WLS... Started. Enter Enterprise Manager Root (SYSMAN) Password : Securing WLS... Successful Restart OMS using 'emctl stop oms -all' and 'emctl start oms' If there are multiple OMSs in this environment, perform this configuration on all of them.
Stop the entire WLS stack, then start the OMS.
$ $OMS_HOME/bin/emctl stop oms -all Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Stopping WebTier... WebTier Successfully Stopped Stopping Oracle Management Server... Oracle Management Server Already Stopped Oracle Management Server is Down Stopping BI Publisher Server... BI Publisher Server Successfully Stopped AdminServer Successfully Stopped BI Publisher Server is Down $ $OMS_HOME/bin/emctl start oms Oracle Enterprise Manager Cloud Control 12c Release 4 Copyright (c) 1996, 2014 Oracle Corporation. All rights reserved. Starting Oracle Management Server... Starting WebTier... WebTier Successfully Started Oracle Management Server Successfully Started Oracle Management Server is Up Starting BI Publisher Server ... BI Publisher Server Successfully Started BI Publisher Server is Up
Visit the WebLogic Server administration console and you should now see that it presents your custom SSL/TLS certificate and no longer uses the demo certificate.
Conclusion
If you have successfully followed these steps, your system should now use your custom SSL/TLS certificates everywhere, and you should no longer experience certificate warnings in your browsers.
Pingback: EM12c R4 SSL Security Checkup Script | Pardy DBA
Thanks for the great page!
Caution when attempting to Secure the OMS console using the the Oracle Wallet from the 12c DB Client instead of the Oracle Wallet supplied with OMS.
Received the following error message.
2015-09-30 04:25:09,643 [main] ERROR oms.SecureConsoleCmds main.187 – Failed to secure the Console: oracle.security.crypto.core.CipherException: Invalid padding string (or incorrect password)
java.io.IOException: oracle.security.crypto.core.CipherException: Invalid padding string (or incorrect password)
at oracle.security.pki.OracleWallet.open(Unknown Source)
Opened the same wallet in version 11.1.1.7.0. Saved it again. Command ran successfully.
Thanks
Karl
Thanks for the additional tips! Getting that indexed into search engines will help people.
Another tip – on the section “Re-secure all agents”
This step can be done as a batch job from the OEM UI.
1) Login as Sysman
2) Navigate to Setup->Manage Cloud Control->Agents
3) Highlight all your agents.
4) Click Secure
5) Enter the agent registration password.
6) Click Submit.
7) Have a coffee while sitting back and watching the pretty graphs of the job securing all your agents.
Cheers
Karl
Hi, one more thing: I have created the wallet with auto_login_local and the crashed with the error:
oracle.security.crypto.core.CipherException: Invalid padding string (or incorrect password).
Changed the wallet to simple auto_login (not local) and it works fine . . .
George
hi All,
can someone share how we can recreate a wallet request..?
Thank you,
Prasad
Hello Prasad,
Do you mean recreating the certificate signing request that comes out of the Oracle wallet to send to either a third party certificate authority or to your internal certificate authority?
If so you can repeat the “orapki wallet export” step above under “Export a certificate signing request”. That will reproduce the CSR for an existing wallet record and you can have it re-signed if needed.
If your question was about some other step, please clarify if you can.
-Brian
Thank you for the Prompt response Brian,
This helps.
Also, if we intend to make use of a self signed certificate, do we need to concatenate the only certificate content to “trusted_certs.txt” ? is that how it works..?
Thanks again,
Prasad
Hi Prasad,
I think you are correct. If you use a self-signed certificate, that same certificate is used to authenticate itself as the root, so yes, I believe that you will need to concatenate only that one certificate’s content into the trusted_certs.txt file. Also, two steps before that, when you add the certificate to the wallet using -trusted_cert, you will not have an intermediate certificate so you should only need to import that certificate once with -trusted_cert and then once again with -user_cert.
Good luck, I hope this helps!
-Brian
Nice instructions. I had just secured my test server last month, but came across something unexpected. Looking the the OMS logs, I noticed that warning messages about using the DemoTrust. So I rolled back everything and tried again.
When I secure WLS, I can confirm in the weblogic console that the admin server and oms are using custom identity & trust stores. However, after securing the OMS, I still see the warnings in the log. secure.log shows that my trusted ca certs were imported into its stores (in the wlserver_10.3 directory because the log shows that’s what it’s using).
Any ideas?
Thanks,
Ten
Hi there,
Bonus points to you for noticing this! I have upgraded to EM13c since making this post, but I can absolutely confirm that I noticed the same thing in the logs when I initially prepared this procedure.
I cannot say for sure if this leaves your EM12c installation vulnerable to still have the widely known demonstration CA certificates trusted by WLS even after applying your own custom certificates. I am inclined to believe the warning message in the logs is true and that the system remains vulnerable.
I filed a security service request at the time on this exact issue you noticed, pointing it out and providing a set of keytool commands to remove the demo CA certs from this file, resulting in a system that does NOT print that warning in the logs on startup. I was advised, after the SR was sent to security, that this was the intended, expected behavior, and that removing the demo certs was not supported. I let it go at that and elected not to publicize the issue (other than hinting at it in this blog post), but I still consider this a potential security issue. It is likely in my opinion that it will not be resolved with a patch unless someone can demonstrate a proof of concept exploit.
In the meantime, if your environment has extreme security requirements, I don’t think it would be a bad idea to script something up to remove these demo certs after applying your own certs, perhaps coupled with another script to restore the demo CA certs prior to patching or upgrading your EM12c in case any of those steps rely (unwisely) on those certs.
When I have a chance, probably Monday, I will reply again and post the keytool commands I used to remove the demo CAs on my system. I do suggest taking care here as it is possible to get your EM12c into a confused setup where you need to restore the various DemoTrust|DemoIdentity files from backup copies to allow the whole thing to start up successfully, so don’t experiment on production without a backup like I did at the time 🙂
Thanks for your post and good luck!
-Brian
Brian,
Thanks for replying so fast. I had the same thoughts of removing the demo CAs. BTW, is this fixed in EM 13?
Ten
I haven’t really checked into securing EM13c beyond the manual yet. There’s some hope with the newer WLS release that this has changed but I need to have a look at it. Thanks again for posting.
-Brian
Pingback: Securing Oracle Enterprise Manager 13c | Pardy DBA
PKI-04006: No matching private key in the wallet
I follow all steps in this article, but getting this error message on this particular step:
orapki wallet add -wallet /app04/oracle/OEM13cR2/WALLET_12302016 -user_cert -cert /app04/oracle/OEM13cR2/WALLET_12302016/user_1230.txt -pwd redacted
Any help will be much appreciated
Hello Vadim,
That error should mean that the wallet you are using as the target when adding the user cert is not the same wallet you used when you first created the key and then exported it to create the CSR. I have seen that when I tried to add a signed certificate to the incorrect wallet.
Try displaying the contents of the WALLET_12302016 wallet and confirm that you see the subject DN in the “Requested certificates” section of the orapki display output, I think you may just be pointing at the wrong wallet.
Good luck!
Hello Brian, thank you for your detailed notes. SSL is totally new to me and I am tasked with fixing some issues resulting from security scan violations from outdated SSL certificates from a our grid control server. I have been reading online and need some clarifications. I am assuming SSL was setup before I joined the project and the certs are now outdated. I will be using federal issued certificates, I just need cloud control (13c) specific instructions on how to replace the new certs with what is currently in Production now and causing security scan violations. Please help me narrow this down. Basically, I am confused and do not know what portion of your instructions above will be valid for my scenario. (instructions on how to replace outdated certs with new issued certs)
Hello Manga,
Thanks for commenting. It sounds like you will need to either renew your existing certificate, or just create a new one. First I think you need to identify the exact issue reported from your security scans: they may be reporting that your certificates have simply expired, or they may be reporting that your certificates are using outdated algorithms like MD5 or SHA-1. You should also determine the exact version of Cloud Control that you are running (EM13c 13.1 R1, or EM13c 13.2 R2) so that you can find the correct documentation to follow.
Once you know your EM13c version and the exact problem with your current certificates, you can proceed from there. Hopefully your site has support from Oracle and you can refer to MOS notes for more information. I suggest reviewing MOS note 2202569.1 as it contains a lot of useful information. If your OMS is up and running, you can run “emctl secdiag openurl -url https://omshostname.domainnname:4903/empbs/upload” (replace omshostname and domainname with the correct hostname and domain name for your site), and that will display your installed certificates. From that output you should be able to find the “Valid from” and “Valid till” lines to see the date your current certificate expires to confirm that it actually has expired.
If it is correct that your OMS certificate has expired, the following steps should allow you to request and install a new certificate that is not expired. (You would need to run different steps if the security issue reported is MD5 or SHA-1 usage.) First, take a backup of the entire OMS server just in case you have problems. If it is on a virtual machine, a snapshot works very well.
1 – Create a new Oracle wallet on your OMS server (this is under the “create an Oracle wallet for the OMS” section in this blog post)
2 – Create a new key in that wallet (in the same section of the blog post, in the “orapki wallet add” command). When you specify the “-dn” parameter to orapki, you should use the same values that were used for your current certificate, which should be visible in the output from the “oemctl secdiag openurl” command I mentioned before. The CN= should match the hostname of your OMS server, the ST= and C= fields should match your current state and country, and the OU= field should match your current OU= (organization unit) field.
3 – Export a “signing request” (in the blog post in the “orapki wallet export” command) for your new key. This will create a new file using the filename specified with the “-request” parameter.
4 – Send the file produced in step 3 to your signing authority. I do not know how your federal issuer receives certificate signing requests, but they should have some documentation available for you.
5 – Wait for the signing authority to send you a signed certificate. They will probably send you back multiple files that include your new certificate and two additional files for their root certificate and their chain certificate. Some signers will only send you your certificate and their root certificate because they do not use chain certificates, your federal issuer should be able to tell you what they will provide.
6 – Once you have received those files, follow the “orapki wallet add” commands in the “Import the root, intermediate, and user certificates into the OMS wallet” section. You will add your certificate with the -user_cert parameter, and the signer’s root+chain certificates with the -trusted_cert parameter. Also make sure to follow the step at the end of this section to create the trusted_certs.txt file.
Now you should have a new wallet with a new certificate. Make sure you have good backups of your server before attempting the final two steps, because you may need to restore from backup if the secure steps fail.
7 – Follow the “Secure the OMS console” section that has you run “emctl secure console -wallet” and provide the path to the new wallet where you imported the signed certificates.
8 – Follow the “Secure the OMS upload port” section that has you run “emctl secure oms -wallet” and provide the path to the new wallet and the trusted_certs.txt file created in step 6.
You are probably all done at this point. Since you are re-using the same federal issuer, you probably will NOT need to re-secure your agents. But, if your federal issuer has changed root or chain certificates since your old certificates were installed, you MAY need to go through the “Re-secure all agents” step in the blog post.
After all this, have your security team re-run their scans and your EM13c environment should now pass, hopefully.
If you feel uncomfortable with these steps, I suggest that you file a service request with Oracle if your site has support, and request their help to guide you through the process of renewing your expired certificate.
Good luck!
-Brian
We have an interesting scenario.
The OMS console has 3rd party cert in play
The OMS upload port has original self-signed (because to implement 3rd party would create a mass outage to 1000’s of agents, we chose to leave this “as-is” for now)
A few AGENTs need 3rd party certs now. But when following your process, they can be secured/started, however the HB status shows “OMS is unreachable with WARN – Ping communication error
o.s.emSDK.agent.comm.exception.VerifyConnectionException [unable to connect to http server at https://xxxxxxx.xxxx.xxx:4888/empbs/upload. [peer not authenticated]]
I assumed I need the 3rd party root and inter CA somehow loaded to the upload port to permit the agent to use the 3rd party user cert when communicating to the upload? How do I tackle that one?
Hi Phil,
That really is an interesting one. I believe your assumption is correct: the OMS upload port server process is failing to authenticate the 3rd party certs the agent(s) present when they connect. I do think there is a way out of this without resecuring thousands of agents, but it may require an OMS bounce, may not be officially supported, and will need a bit of testing on your side.
First off, are you on EM12c or EM13c? The directory paths and commands I’m about to paste in will definitely vary depending on your version. I only have 13c available to refer to right now.
In EM13c, Oracle HTTP Server/OHS runs the process that listens on the OMS upload port (this may be done by WLS in 12c instead but I think it is OHS there too). Multiple OHS instances run to service OMS upload and other ports, and they use wallets configured in $INSTANCE_BASE//user_projects/domains/GCDomain/config/fmwconfig/components/OHS/instances/ohs1/keystores, specifically in the ‘upload’ subdirectory for the OMS upload port (in some early 12c versions this may use JKS keystores instead, but they’re used similarly). If you manually add the third party root and intermediate certificates to these wallets using something like “$MW_HOME/oracle_common/bin/orapki wallet add -wallet upload -trusted_cert -cert rootcert.txt”, then bounce the whole EM stack, I think that may take care of this for you.
Make sure to have backups of these files just in case and do test out adding the root/intermediate certs on a copy to make sure you get the syntax right, and the “orapki wallet display -wallet upload” output appears to list the root/intermediate certs as trusted.
If you ever have to re-secure the OMS upload port with the demo cert again in the future, it will very likely overwrite this change and require you to add the third party root/intermediate certs back again. If you’re on early 12c you might be stuck using keytool to do the same sort of operation to JKS keystores instead, I don’t remember which format the demo cert used on 12c when not customized.
Hopefully this all makes sense, good luck! Always doublecheck your backups when working in these internal EM files.
So its 12c I am on, and am looking at files called b64LocalCertificate.txt & b64InternetCertificate.txt which may be in play as the “defaults” for the upload port OMS_INST/em/EMGC_OMS1/sysman/config and am not sure where the keystores/wallets for 12c OMS are located and maybe all I need to do is add the agent CA/inter certs into the b64InternetCertificate.txt file?
I get that this may be bending some rules, but Oracle haven’t really created many (usual lack of specific detailed docs etc leave us googling!) so am confident at hacking/restoring as necessary.
Hi Phil.
Those base64 encoded certificates sound familiar, this is bringing my memory back. As I recall, those files contain the demo certs and are used when securing and de-securing WLS, and are also used as the base demo certs when doing a re-secure of any component using the demo cert. I seem to remember having a bad time later on when I tried editing those files directly. I’ve found some notes from back then.
Take a look at the directories under $EM_INSTANCE_BASE/WebTierIH1/config/OHS/ohs1/keystores/ – from these notes I was working with the ‘proxy’ subdirectory before but I think when running on demo certs there will be an ‘upload’ directory there too. If OHS drives the upload port in 12c this where they should be, otherwise if it’s under WLS control another place to take a look is $EM_INSTANCE_BASE/em/EMGC_OMS1/sysman/config/keystore at the WLSTrustStore.jks file. I think to get things flowing again with the least risk of having to re-secure the OMS with the demo cert and thus get forced to re-secure thousands of agents, that you’re better off editing the generated wallets/keystores directly rather than editing the source data that is used to generate those files.
I think if you use keytool and add the root/intermediate certs to WLSTrustStore.jks (or orapki if you find a wallet under …./keystores/upload) that will take care of this, probably requiring a bounce or to do it during OMS downtime. Something like “keytool -import -trustcacerts -alias myroot -file rootcert.cer -keystore WLSTrustStore.jks”, possibly repeated on DemoTrust.jks. The default password for the demo trust keystore is DemoTrustKeyStorePassPhrase
From my notes, when securing with a demo cert the OMS takes the certs out of $WL_HOME/server/lib/cacerts and uses them to generate DemoTrust.jks, then uses DemoTrust.jks to populate WLSTrustStore.jks. A ‘permanent’ fix probably would go in that cacerts file to have your desired third party certs trusted every time you regenerate certs.
Good luck! I relied liberally on VM snapshots while getting all this stuff sorted out a few years back.
Thanks again for the steer on this Brian, I have located the upload wallet “OMS_INST//WebTierIH1/config/OHS/ohs1/keystores/upload/cwallet.sso” and am now stuck trying to play “guess the password” for it. DemoTrustKeyStorePassPhrase didn’t work, I guess I need to raise an S/R with oracle. Will report back on progress either way. If I can add the inter and root certs for the agent cert here, I think I will be cookin’ on gas…
The password might be: changeit
Or possibly DemoWalletPassPhrase
They have the details on these buried somewhere in the manual. It also MIGHT be any wallet password you specified when securing the rest of the OMS with the third party cert.
Also try: DemoKeyStorePassPhrase (no Trust this time)
😦 all failed (included my own for this sys, just in case) The sso file dates 2014… Thanks for trying… Will get hold of the oracle dev team somehow to give up their guessable credentials to me.
Fixed my issue trying to get agent to use 3rd party cert whilst having the oms upload port remain on the demo cert. It is basically in an OEM support note
“EM 13c, 12c: How to Configure the Enterprise Manager Management Agent for Secure Socket Layer (SSL) Certificates (Doc ID 2213661.1)”.
Specifically section B, step 9:
If the OMS is secured with default EM certificates, then the EM root certificate needs to be imported to this wallet. The EM OMS root certificate is present in /em/EMGC_OMS1/sysman/config/b64LocalCertificate.txt
> ./orapki wallet add -wallet /home/oracle/wallets -trusted_cert -cert /em/EMGC_OMS1/sysman/config/b64LocalCertificate.txt -pwd
I needed to replace an expiring user cert. I could not find anything on this topic, so I just plowed ahead. Actually, the CA had changed to a more complex encryption, also. I replaced all the needed chain PEM files in the current wallet that was configured to secure the console. I restarted the OEM and it was happy with the new files. Seems as long as there is a valid chain in the wallet, WL does the right thing. I was pleasantly surprised.
When I follow this process for the agents, I run into a weird situation. I copy the .sso file and restarting the agent and I can verify the certs are working. However, when I go to secure the agent afterwards deletes the .sso file and goes back to the original cert. I feel like there is a step missing somewhere!
Hi Jason,
Are you re-securing the agents with “emctl secure agent” *after* you deploy the cwallet.sso file to the $AGENT_INSTANCE_DIR/sysman/config/server/ directory? The “emctl secure agent” step is required after applying (or modifying) the certificate on the OMS upload port, but to my knowledge you are not required to re-secure the agent after configuring the agent wallet.
I think the necessary order of operations is:
– Apply cert to OMS upload port
– Re-secure all agents
– Prepare agent wallets
– Stop agent
– Copy cwallet.sso to agent
– Start agent
– Done
I believe, but I have not doublechecked, that the “emctl secure agent” step re-generates new, mostly-empty agent wallets that only contain a certificate trust path for the OMS upload port, which means you would need to stop the agent, re-copy the cwallet.sso file to the $AGENT_INSTANCE_DIR/sysman/config/server/ directory, then start the agent.
You are correct I did secure the agent after restarting it. When I was attempting to do patches from OEM I was getting failures when trying to stage the patches unable to connect to http port because [handshake has no peer]. When gooogling .. it stated I may need to resecure the agent upload port using ./emctl secure agent -emdWalletSrcUrl https://oemblahblahserver:4903/empbs/upload which I did .. and the staging started working.. but at the same time removed the cwallet.sso file (all other communication with agent was working fine up till when I tried doing the patching)
Got it, that makes sense now. I think at this point if you stop the agent, put the cwallet.sso file back in place for the agent, and start the agent, then one of two things will happen. Either everything will just work fine at that point, or you may see the “handshake has no peer” error again.
If you get the “handshake has no peer” error again, I think that usually means the OMS is not able to validate the agent certificate. Are you using third-party commercial certificates for all of these? Or are you using self-generated certificates from an internal root CA? The OMS wallet needs to contain a trustedCert entry for the root certificate that has signed the agent certificate.
In my case with the examples above, when I create the OMS wallet I import two trusted certificates:
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -trusted_cert -cert ~/TrustedRoot.cer -pwd ‘[REDACTED]’
Oracle PKI Tool : Version 11.1.1.7.0
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
$ $MW_HOME/oracle_common/bin/orapki wallet add -wallet $ORACLE_BASE/oemwallet -trusted_cert -cert ~/DigiCertCA2.cer -pwd ‘[REDACTED]’
Oracle PKI Tool : Version 11.1.1.7.0
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.
The TrustedRoot.cer in my case comes from DigiCert and is the same root certificate used in signing the agent certs. If your cert authority uses multiple root certificates or if you use a different cert authority for the OMS versus the agents, you will probably need to import both sets of root certificates into both the OMS wallet and the agent wallets.
Thank you for your quick replies! I am using Third Party Certificates (InCommon) and when we get the certificates back I get a combined intermediate/root cert so I have to break out the certs into three separate certs for the chain, and I have been adding all three to all wallets (agents and OMS)
Brian,
Thanks for the wonderful post. Quick question…
Per “Configure the agents to use their wallets”, the instructions say only to copy the cwallet.sso file from agent wallet directory. What about ewallet.p12? Isn’t that the file that actually contains the root, intermediate and user certificates generated for the agent host?
Thanks,
Rama
Hi Rama,
I am glad the post was helpful. The cwallet.sso file, as I understand it, contains the same contents as the ewallet.p12 file, with the difference being that no password is required to open the cwallet.sso file (when the -auto_login or -auto_login_local parameters are used with orapki). I am not sure if the management agents can be configured to specify a wallet password, but if there is an option in agent.properties or somewhere else to do that you would probably need to use the ewallet.p12 file instead of cwallet.sso.
It does seem to work on my systems with just the cwallet.sso file provided.
Cheers!
-Brian
Hi Brian,
Great post!
Quick question..how do you address the scenario where a single OMS Server is setup on a Server by name ex. server1.test.com and not behind any LB and the organizational guideline for raising CSR is to use the service name instead of “server” name?
Would setting up a CNAME ex. oem.test.com for server1.test.com and then raising CSR for oem.test.com as CN work ok?
And this is what Note 2202569.1 says…
Note:
1. While raising the CSR, specify the host name of the machine where the OMS is installed or the Load Balancer(SLB) Name if the OMS is behind the Load Balancer for Common Name(CN). Hostname should be same as used by OMS or SLB and in same case.
Cheers,
Raj
Hi there,
Thanks for this useful article and related comments to help provide further clarity.
Quite some time since any new posts here, but still relevant article since top of search engine results, so…
My question is, if unable to generate/sign csr using orapki, can we use an openssl keystore with the full certification chain and then convert this using orapki and secure console this way?
In my attempt, orapki converts keystore fine with sso file, and further validated with displayingn the wallet (some duplicate trust certs show for some reason), however, proceeding with securing the console, results in error,
2022-04-14 08:41:05,895 [main] INFO util.EmctlUtil logp.251 – Connecting over t3s to: / using id: system
2022-04-14 08:41:07,875 [main] INFO mas.CredStoreUtil logp.251 – getCredential : Got creds for mapName -EM keyName – REPOS_DETAILS
2022-04-14 08:41:09,769 [main] INFO util.EmctlUtil logp.251 – Failed to get repos connection using info from AdminServer. Ignoring the exception: ORA-01017: invalid username/password; logon denied
The report db is on same server as the OMS/WLS. Anyone have any insights in to this one, or validating the credentials stored using mapName -EM keyName? Looks like it’s using system as the repo login, and it must have incorrect password stored in some credentialmgr/store somewhere.