CUCM Security Tips
- With CUCM in non-secure (default) mode, you may use secure SIP trunk, but you cannot use secure SCCP endpoints (secure media resource, secure SCCP phones). You may try to telnet to CUCM on port 2443 (secure SCCP port), the port is closed.
- The easiest way to put CUCM in mixed-mode is to use CLI command "utils ctl set-cluster mixed-mode". Ref: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/215411-enable-encryption-on-cisco-unified-commu.html
- Since from CUCM 11.5U3, you'll need an "encryption license" to enable mixed mode. License if free, but you'll have to get it from Cisco, either through PUT (Product Upgrade Tool) or open a license case. Ref: https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/11_5_1_SU2/releasenotes/cplm_b_release-notes-cplm-1151su2/cplm_b_release-notes-cplm-1151su2_chapter_01.html#reference_54690C68E3499E0FC2E9BBD6B9AC66A8
- Secure Conference Bridge has special requirement. Though configuration for secure conference bridge (CFB) is pretty much the same as secure transcoder(TRA) and secure media termination point(MTP), secure CFB requires the register name to match the hostname portion of the subject name (in the certificate/trust-point). For instance,
- You router's FQDN is R1.MyCompany.com.
- Most likely you would enroll a certificate for the router with a subject name "R1.MyCompany.com".
- On the router, you created a trust point R1-Cert to hold the above certificate.
- You would think you could use R1-Cert for secure SIP-trunk, secure media resource, etc. Until it comes to the point that you try to register a secure conference bridge.
- On CUCM, you saw the conference bridge status is "rejected", yet secure transcoder and MTP are registered. So it's unlikely certificate problem.
- On CUCM, you named them R1-CFB, R1-TRA, and R1-MTP
The problem is with the name "R1-CFB". It has to match with the hostname portion in the certificate (which is "R1" in this case). OK, no big deal, I'll just change the name from "R1-CFB" to "R1". Well... you cannot do that. Because IOS won't accept a conference bridge name shorter than 6 characters or longer than 15 characters. So you either change the router name (make it between 6 and 15 characters), re-enroll the certificate; or keep the router name/keep the router certificate, and enroll another certificate for conference bridge (yes, for conference bridge only). For instance,
- Your router certificate is R1.MyCompany.com
- Your conference bridge certificate is R1-CFB.MyCompany.com
No, you don't need DNS entry created for those names. You may use IP addresses and TLS handshake will still succeed.
- On IOS-XE (all ISR G3 / ISR 4000 series), Cisco decided not to support secure transcoding, which means, when you create transcoding profile on the router, there's no "security" option available. Available options are:
- Register non-secure transacoder to CUCM (application sccp)
- Register LTI transcoder to the router (application cube)
- No transcoding at all. on IOS-XE, SRTP to RTP internetworking does not require transcoding.
- Crypto Mismatch in ad-hoc conference (call dropped)
31948894.000 |11:19:34.039 |SdlSig |MXErrorReport |interfacesEstablished |MediaExchange(3,100,114,571) |AgenaInterface(3,100,11,249) |3,100,247,81913.201^131.7.195.252^* |[R:N-H:0,N:2,L:0,V:0,Z:0,D:0] error=0 CallMediaFailureCause=block unencrypted media Reason=prepareAndSendOLC - Serv Param 'Block Unencrypted Calls' is true and the call is unencrypted. Hence blocking the call.
31948895.000 |11:19:34.039 |SdlSig |MXErrorReport |waitStopped |MediaExchange(3,100,114,571) |AgenaInterface(3,100,11,249) |3,100,247,81913.201^131.7.195.252^* |[R:N-H:0,N:4,L:0,V:0,Z:0,D:0] error=0 CallMediaFailureCause=block unencrypted media Reason=openOutgoingAudioChannel - Serv Param 'Block Unencrypted Calls' is true and sRTP keys not generated successfully. Hence blocking the call.
The above messages indicate there's a crypto mismatch between the conference resource and the intended call leg. Use "show sccp" command to see support crypto on conference resource. e.g.:
Router#show sccp
Conferencing Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 143.124.8.141, Port Number: 2443
TCP Link Status: CONNECTED, Profile Identifier: 1
Security
Signaling Security: ENCRYPTED TLS
Media Security: SRTP
Supported crypto suites: AES_CM_128_HMAC_SHA1_32, AES_CM_128_HMAC_SHA1_80
On CUBE, create a voice class for crypto and apply it to the dial-peer:
voice class srtp-crypto 1
crypto 1 AES_CM_128_HMAC_SHA1_32
crypto 2 AES_CM_128_HMAC_SHA1_80
!
dial-peer voice 50 voip
voice-class sip srtp-crypto 1
Reference #1: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/srtp-rtp-interworking.html
Reference #2: https://www.cisco.com/c/en/us/td/docs/routers/access/4400/software/configuration/xe-16-9/isr4400swcfg-xe-16-9-book/configuring_voice_functionality.html#concept_xd5_zvc_sbb (For SCCP-based signalling, only TLS_RSA_WITH_AES_128_CBC_SHA cipher suite is supported）
Use IOS router as CA (Certificate Authority) Server
If you have a router handy (especially with GNS3), IOS CA is probably the most convenient way to sign certificates. Though you may set up IOS CA for online enrollment, I strong recommend you practice terminal method. In most cases, terminal is the quickest (and probably the only) way to get your job done.
To set up CA server on IOS, you just need a couple commands:
conf t
crypto key generate rsa general-keys exportable label myCA modulus 2048
crypto key export rsa myCA pem url nvram: des myCAkey
ip http server
crypto pki server myDB
database level minimum
database url nvram:
issuer-name cn=myCA, l=Dallas, c=US
lifetime certificate 7305
grant auto
no shut
From a router (say, R1) you want to enroll certificate, do the following:
crypto pki trustpoint R1-Cert
serial-number none
fqdn none
ip-address none
subject-name cn=R1.mycompany.com
revocation-check none
rsakeypair MyRSAkey
enrollment terminal
R1 will generate CSR and print it on the terminal. You're going to copy/paste the CSR to the CA server we created above. An example output is like below:
% The fully-qualified domain name will not be included in the certificate
Display Certificate Request to terminal? [yes/no]: yes
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqvvg3/mSs86PF/4EFGmLt+hbmj0YmBM8
JOfHLJ0lC1uEEYMxe/8+4D+J5vTrR3TgyMy2xkW2eUmZHWnFbWiGDhVE9QrnBGHV
YcS6eFL1WUMlk1y7PWICX8sBWmig6t3D28pMdvlLQTaLAyn9hiJvm6VPEhK3Pao7
+kwTpMPP5AkCAwEAAaAhMB8GCSqGSIb3DQEJDjESMBAwDgYDVR0PAQH/BAQDAgWg
MA0GCSqGSIb3DQEBBQUAA4GBAJ7VyBjaiu2t8IbTeKKBGzPgVqaja4NBTDkl5bHX
1OUyBJ0Ih02NM9Cq07HtdwaiWXiAcPdqPYOVfLHNM50FuC1e1aag0QgGWW126Na5
buyLyg3Daf67wymMhAyrKhFTkhGlIO1gJ739c9yPpVf2TUVtjMWNl+Fz6Je52qSF
On CA server, use global command "crypto pki server myDB request PKCS10 terminal" to sign a CSR. An example output is like below:
CA#crypto pki server myDB request PKCS10 terminal
PKCS10 request in base64 or pem
% Enter Base64 encoded or PEM formatted PKCS10 enrollment request.
% End with a blank line or "quit" on a line by itself.
MIIBfzCB6QIBADAfMR0wGwYDVQQDExRteUNVQkUuZXhhbXBsZS5sb2NhbDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqvvg3/mSs86PF/4EFGmLt+hbmj0YmBM8
JOfHLJ0lC1uEEYMxe/8+4D+J5vTrR3TgyMy2xkW2eUmZHWnFbWiGDhVE9QrnBGHV
YcS6eFL1WUMlk1y7PWICX8sBWmig6t3D28pMdvlLQTaLAyn9hiJvm6VPEhK3Pao7
+kwTpMPP5AkCAwEAAaAhMB8GCSqGSIb3DQEJDjESMBAwDgYDVR0PAQH/BAQDAgWg
MA0GCSqGSIb3DQEBBQUAA4GBAJ7VyBjaiu2t8IbTeKKBGzPgVqaja4NBTDkl5bHX
1OUyBJ0Ih02NM9Cq07HtdwaiWXiAcPdqPYOVfLHNM50FuC1e1aag0QgGWW126Na5
buyLyg3Daf67wymMhAyrKhFTkhGlIO1gJ739c9yPpVf2TUVtjMWNl+Fz6Je52qSF
97iD
% Granted certificate:
MIICFDCCAX2gAwIBAgIBBDANBgkqhkiG9w0BAQQFADAtMQswCQYDVQQGEwJVUzEP
MA0GA1UEBxMGRGFsbGFzMQ0wCwYDVQQDEwRteUNBMB4XDTIwMTAxNjEzNTI0M1oX
DTIzMTAxNjAwMjAzMFowHzEdMBsGA1UEAxMUbXlDVUJFLmV4YW1wbGUubG9jYWww
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKr74N/5krPOjxf+BBRpi7foW5o9
GJgTPCTnxyydJQtbhBGDMXv/PuA/ieb060d04MjMtsZFtnlJmR1pxW1ohg4VRPUK
5wRh1WHEunhS9VlDJZNcuz1iAl/LAVpooOrdw9vKTHb5S0E2iwMp/YYib5ulTxIS
tz2qO/pME6TDz+QJAgMBAAGjUjBQMA4GA1UdDwEB/wQEAwIFoDAfBgNVHSMEGDAW
gBTp6GtJM5PvbI3sgyhm0JTXwyp87TAdBgNVHQ4EFgQU8wuU1JkqJ5iCnGNsFDPW
eo/WSE0wDQYJKoZIhvcNAQEEBQADgYEAOup/WXtvcJ7piHuWP8kA9IyYaGMrAsMr
dDlIsQ2BqexzrQiWKRNVVzUl/33FFD6eIi+UN7ZnQG/CspL2xTI2FRQ5KWBDJC0r
Znga3d2ITEWHwpn7yhscnI/B9MFABZgBAfXVFjUkZmV6Mlmjz/E+GDX+G1adnTcA
HbA6IdsOoFE=
CA#
The yellow portion above is our input. The green portion the the signed certificate (for R1). We're going to copy/paste it to R1. This is called "import" a signed certificate into R1. But before importing a signed certificate, we need to import the signer (CA) certificate first. On CA, use config command "crypto pki export myDB pem terminal" to export CA certificate. An example is as below:
% The specified trustpoint is not enrolled (myDB).
% Only export the CA certificate in PEM format.
% CA certificate:
-----BEGIN CERTIFICATE-----
MIICMzCCAZygAwIBAgIBATANBgkqhkiG9w0BAQQFADAtMQswCQYDVQQGEwJVUzEP
MA0GA1UEBxMGRGFsbGFzMQ0wCwYDVQQDEwRteUNBMB4XDTIwMTAxNjAwMjAzMFoX
DTIzMTAxNjAwMjAzMFowLTELMAkGA1UEBhMCVVMxDzANBgNVBAcTBkRhbGxhczEN
MAsGA1UEAxMEbXlDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAgn+6fx3p
Km9VI/kLO32o5SPM184fbWBGm5OWq47B1PP8FfiyrboftDjClAl+AYXrV3mp79rt
jifQujen4vukCet/UNC+1U5txG8Y27wf+Zz4LQKlQWfXnXDUyQZ6DBbHCQrYs5Wm
9QqpDmq6JSfKaymAfY3aYBqp0SJjlR8+f/kCAwEAAaNjMGEwDwYDVR0TAQH/BAUw
AwEB/zAOBgNVHQ8BAf8EBAMCAYYwHwYDVR0jBBgwFoAU6ehrSTOT72yN7IMoZtCU
18MqfO0wHQYDVR0OBBYEFOnoa0kzk+9sjeyDKGbQlNfDKnztMA0GCSqGSIb3DQEB
BAUAA4GBAEMKnOCtDz9UMP48liWPXBLzImwrr81ARfYnjUk5b9h+3r2xB7t4welr
y+bRNQGcBT7tnWI16KMFUmfijqD4NsGFsgxObGJT4eF3IZeLgiRCTmz8HEhP3chb
aTRkht8WRNchU+YO1Nds/V/j/vD1x/eaeL9Myqb8Zh4JgTHaB+/k
Now on router R1, do the following:
- Import CA certificate with config command "crypto pki authenticate R1-Cert". R1-Cert is the trust point name, which is just a placeholder for a cert and its signer. Paste the CA cert (the 2nd green block above).
- Import R1 cert with config command "crypto pki import R1-Cert cert". Paste the signed R1 cert (the 1st green block above).
Now you have successfully installed certificate on R1.
If you got "Authentication failed - could not validate certificate" when trying to install the R1 certificate, it is most likely you have Revocation-Check enabled at the R1-cert trust-point.
Instead of:
revocation-check none
You might have:
revocation-check crl
To fix the problem, set the revocation-check to none. Then you'll have to re-generate the CSR and have it signed again by CA.
No comments:
Post a Comment