I may be wrong, but I think the only difference between Cisco’s Quality Management and Advanced Quality Management is the screen recording component, so these same steps may work fine for the regular QM piece in addition to AQM.
You’re probably here because you want to have a real SSL certificate, i.e. public CA-issued, on your AQM server. This is a big pain in the ass even by Cisco standards. If you’re running AQM for the purposes of doing call recording of call center agents, you may have run into an issue with recording sensitive data and compliance with various industry / statutory requirements, such as HIPAA, PCI, GDPR, etc. Cisco provides NO method to secure call recordings in a manner acceptable to most applicable regulations, which means if you’re recording your agents, those recordings bring the entire phone system into scope of compliance/certification. Well, the whole Unified Communications suite is a joke from a security perspective, so there’s simply no way it will stand up to those types of certifications, meaning you can’t have your call recordings contain sensitive information.
The way most environments work around this is to make use of a feature which allows agents to temporarily opt out of call recording when sensitive data is going to be heard and transcribed. You then of course have to have monitoring of who is opting out, how often, and what numbers are on the other end, to ensure they aren’t using that privilege as a way around detection of disallowed behavior.
So let’s get to it. The stupid SSL cert the AQM interface uses is of course self-signed and not recognized by any browser. Cisco’s wonderful solution is not a real cert, it’s to install your self -signed cert authority into every desktop that might access the AQM server; ROFL.
Installing a real certificate needs to be done not only from command prompt, but an administrative command prompt. In the following command snippets, you’ll see reference to a password of C@labr1o. This is not for the purpose of example, it is literally the password to use in these commands, as that is what Cisco sets it to.
Step 1 – delete the current self signed cert key. You could skip this step and simply output a CSR based on the current key, but if you have not previously gone through this process, the current key is likely 1024-bit, and SHA1 signed, and that can also be an issue with certain browsers, so you’re better off removing it and generating a new SHA2 2048-bit or 4096-bit key. Remember, the following is to be run from an administrative command prompt; i.e. cmd.exe right clicked to run as administrator:
C:\Windows\system32> cd c:\program files\cisco\wfo_qm\java\bin
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -delete -alias jettyCode language: CSS (css)
Step 2 – generate a new 2048-bit or 4096-bit key, which requires a -keysize argument:
c:\Program Files\Cisco\WFO_QM\Java\bin>keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -alias jetty -sigalg sha256WithRSA -keysize 2048 -genkey -keyalg RSACode language: CSS (css)
The above code will require you to walk through a familiar OpenSSL-style sequence of prompts to build the data which will ultimately end up in your certificate signing request, even though we’re still at the key generation stage. Where it is stupid is the first question, which is your first and last name. No, it does not actually want your first and last name, it wants the value it will insert into the ‘common name’ field of the CSR, i.e. CN=, which is the fully qualified domain name your AQM server will be reachable as. So, put that in instead of your name:
Step 3 – Hooray, time to spit out a CSR. This command will require customization to specify the output location, file name, and if you’re doing a SAN certificate, the SAN name as an additional option. You can leave the -ext san= part off if you’re only needing the common name from the prior command; i.e. a certificate specific to your AQM server, which is what I generally do since those certs are a few dollars/year.
With SAN specified:
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\Program Files\Common Files\QM\config\.keystore" -storepass C@labr1o -certreq -alias jetty -file "C:\users\username\Desktop\aqm-server.mydomain.com.csr -ext san=dns:aqm-server.mydomain.comCode language: CSS (css)
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\Program Files\Common Files\QM\config\.keystore" -storepass C@labr1o -certreq -alias jetty -file "C:\users\username\Desktop\aqm-server.mydomain.com.csrCode language: CSS (css)
Step 4 – take that CSR and get a certificate from your authority of choice.
Step 5 – install the resulting certificate and any relevant intermediate certificates. In my case, I also needed to install the issuing root’s public cert, even though the system not only has it, but the command even advises you the system has it. Before I did that, it would not permit me to install my issued certificate. In my case, the certificate was from Comodo, so that required adding the AddTrust root, the AddTrust intermediate, and the Comodo intermediate:
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -importcert -trustcacerts -alias AddtrustRoot -file c:\users\username\desktop\addroot.crt Certificate already exists in system-wide CA keystore under alias <addtrustexternalca> Do you still want to add it to your own keystore? [no]: yes Certificate was added to keystoreCode language: Bash (bash)
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -importcert -trustcacerts -alias AddTrust -file c:\users\username\desktop\addtrust.crt Certificate was added to keystoreCode language: CSS (css)
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -importcert -trustcacerts -alias Comodo -file c:\users\username\desktop\comodo.crt Certificate was added to keystoreCode language: CSS (css)
c:\Program Files\Cisco\WFO_QM\Java\bin> keytool.exe -keystore "C:\program files\common files\qm\config\.keystore" -storepass C@labr1o -importcert -alias jetty -file c:\users\username\desktop\cert.crt Certificate reply was installed in keystoreCode language: CSS (css)
Phew, it’s there. Now, Cisco’s documentation at https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/workforce_optimization/qm_11x/installation/guide/qm-installation-guide-cisco-ccx-110.pdf suggests all you need do now is restart the “Jetty” service, which you won’t find, as it’s actually named “Monitoring and Recording Jetty Service”. That did not work for me, in fact doing that took the web service down regardless of whether Jetty was running or not. I gave it a reboot instead, seemed to fix things.
Are we done? Perhaps not. If you’re using Firefox, you may be greeted by this error:
Secure Connection Failed
An error occurred during a connection to pbx-aqm.mivamerchant.net. SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. Error code: SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY
Firefox requires a >512bit DH key due to Logjam. Oddly, at the time of this writing, my versions of Chrome (72.0.3626.28) and Safari (12.0.2) don’t seem to care.
I don’t have time to work on that currently but will update the article as time allows, assuming I find a solution.