Configuring a Cisco 2851 cube for Office 365 integration

garthladlow · ‎05-27-2013

Configuring a Cisco 2851 cube for Office 365 integration, the following is the Crypto config required, have not included the dial peers.

Used the following pages as references

http://www.cisco.com/image/gif/paws/63456/sslm-csr.pdf
https://supportforums.cisco.com/message/3243939#3243939
http://www.cisco.com/image/gif/paws/100446/cube_sip_tls.pdf

Some useful debugging commands below incase of issues.

show sip−ua connections tcp tls brief
show sip−ua connections tcp tls detail

debug crypto pki transactions
debug crypto pki messages
debug crypto pki validation

debug ccsip messages
debug ccsip error

debug ssl openssl errors

debug ssl openssl msg

debug ssl openssl states

In summary create three trustpoints root, primary and secondary, create a geotrust trustpoint, import required certificates.

!
! Generate the RSA keys, trustpoint and enroll, required to generate a CSR.

!

1. Generate a 2048 bit key

(config)#crypto key generate rsa general-keys label <key-name> exportable

Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 2048
% Generating 2048 bit RSA keys, keys will be exportable...[OK]

2. Create the trustpoint, the CN name in the subject-name field must match what is in the Office365 config, as per

http://help.outlook.com/en-AU/140/gg702672.aspx

crypto ca trustpoint <trustpoint name>

enrollment terminal pem

subject-name <your information here>

fqdn <your fqdn here should be the same as the CN>

rsakeypair <key-name from above>

3. Generate the CSR.

crypto ca enrol <trustpoint name from above>

% Start certificate enrollment ..

% The subject name in the certificate will include: <..omitted..>

% The subject name in the certificate will include:

<..omitted..>

% Include the router serial number in the subject name? [yes/no]: no

% Include an IP address in the subject name? [no]: no

Display Certificate Request to terminal? [yes/no]: yes

Certificate Request follows:

-----BEGIN CERTIFICATE REQUEST-----

<..omitted..>

-----END CERTIFICATE REQUEST-----

Pass the above certificate request onto your SSL provider, in the example below we are using Digicert, the files you get back from your SSL provider will be used in the following steps.

!
! Create the root point trustpoint
!

crypto pki trustpoint root
enrollment terminal
revocation-check none
!

!
! Import the root cert, this is the TrustRoot.crt file, it's in the cert key files from Digicert
!

Crypto ca authenticate root

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

<..omitted..>

-----END CERTIFICATE-----

!
! Create the Intermediate primary trust point
!

crypto pki trustpoint intermediate-primary

enrollment terminal

chain-validation continue root

revocation-check none

!
! Import the intermediate certificate, this is the Digicert.crt file, it's in the cert key files you Digicert
!

crypto ca authenticate intermediate-primary

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

<..omitted..>

-----END CERTIFICATE-----

!
! Create the Intermediate secondary trust point
!

crypto pki trustpoint intermediate-secondary
enrollment terminal
subject-name <same as the subject_name in step 2 above>
chain-validation continue intermediate-primary
revocation-check crl
rsakeypair <key-name from above>

!

! Import the intermediate certificate, this is the <fqdn>.crt file you receive from Digicert

!

crypto ca authenticate intermediate-secondary

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

<..omitted..>

-----END CERTIFICATE-----

! Import the intermediate-secondary certificate,  this is the <fqdn>.crt file you receive from Digicert

! This is similar to the above step but required

crypto ca import intermediate-secondary certificate

-----BEGIN CERTIFICATE-----

<..omitted..>

-----END CERTIFICATE-----

!
! Create a Geotrust trustpoint, this is the SSL provider used by Microsoft, this screwed me for a few days.
!

crypto pki trustpoint geotrust

enrollment terminal pem
revocation-check none

!
! Import the Geotrust Root certificate

! File from https://www.cybertrust.ne.jp/SureServer/file/root_ca/BCTRoot.txt

!

Crypto ca authenticate geotrust

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----
<..omitted..>
<..omitted..>
-----END CERTIFICATE------

!

! Configure HTTP to use the trustpoint

!

no ip http server

! if using aaa

ip http authentication aaa
ip http secure-server
ip http secure-trustpoint intermediate-secondary

Check the Digicert keys are valid, you may need to add fw rules to allow access

http://www.digicert.com/help/index.htm

Hope the above helps or points you in the right direction.

israelcortes · ‎07-26-2013

I have a CUCM on premises running the latest ver 9.1 and we are wanting to push voice mail into the cloud utilizing MSFT's latest version of Exchange 2013. Why does this need to be so hard? This is not bleeding edge in terms of communication.

Thanks for the info. As I gather up bits and pieces of about CUBE and O365 I am running into a lot of garbage information.

It seems that the CUBE intergration with hosted Exchange worked in an earlier version and now in Exchange 2013 MSFT is recommending you use an SBC to communicate to thier SBC in the cloud envrionment.

I have purchased a SBC but now having some issues with the device, we did not even get passed the configuration stage before the device started acting up and now we are in some sort of "the enginners in Israel are looking at the issue" which is utter BS. We have been delayed in going forward with Exchange 2013 due to a inferior product. These Session Border Control devices are a mixed bag of needed and unnessecary expense but in MSFT eyes they are needed to connect to thier cloud offering. I will give people out there advice, beware of these SBC products. Some of them run on such antiquated software and the return policys are draconian. I guess you can only make so much money selling SBC's so returning them for a refund is not in thier best business interest. We paid close to 11K for the device with accelerated remote support to get the device installed quickly.

I know MSFT recommends using an approved SBC for Exchange O365 2013 but what has changed in the past 3 years that you can't use the Cisco CUBE router? Security? A new protocol? Or just the sake of adding addtional hardware in your envrionment? This is 2013 why are we still in the business of complicating communications?

If MSFT does not support it thats fine I'll be the guinea pig to get this running.

Oleg Serstjuk · ‎04-26-2017

Thanks a lot for the detailed guide on this, it helped me out!

Want to add some details to this as its poorly documented everywhere and if your new to certs trying to configure them on IOS it's not easy

---------------------------------------------------------------------------------------------------

Another thing thing I want to detail is the geotrust - this is very important and can be easily overlooked - NOR IS IT DOCUMENTED by Microsoft or Cisco

When you initiate a handshake you send clienthello, then receive serverhello, followed by receiving certificate from server. If you do not have the root cert to match this server certificate on the GW, TLS handshake will fail as the GW will not know the issuer or trust the certificate.

On windows you have by default a bank of root certificates issuers that are trusted i.e GoDaddy CyberTrust etc...... but here the GW, it only knows about the ones you import

Best place to find these root certs is on your own laptop run... certmgr.msc trusted root cert authorities--> certificates and download them from here to paste to your GW in pem format - ie. begin certificate----end certificate

to get o365 working in our case we needed to use "Baltimore CyberTrust Root" - that can be found above

you will also need the GoDaddy root Certificate - if GoDaddy doesn't provide this to you - "Go Daddy Root Certificate Authority - G2"

----------------------------------------------------------------------------------------------------

Here is what you get from GoDaddy when you download the Tomcat certificates

b42a158d61851696.crt - this is your CA signed certificate

gd_bundle-g2-g1.crt - this is the intermediate certificate chain - contain about 3-4 certs - I dont think these are needed for this handshake but I have imported them anyway

gdig2.crt - this is an intermediate certificate

----------------------------------------------------------------------------------------------------

This is my configuration that was used with office 365 - this will also work for any other client to server TLS encryption eg, TLS to SIP provider or some other 3rd party server etc...

This is created to generate the CSR for your certificate issuer and includes the Subject attributes with "CN" being the most important one for o365 as this is checked in TLS handshake

This is also used to hold 2 certificates, you CA intermediate certificate - "gdig2.crt"(which you authenticate) and your CA signed certificate - "b42a158d61851696.crt" (which you import) - in that order - see below

crypto pki trustpoint o365trustpoint

enrollment terminal pem

fqdn o365vm.example.co.uk

subject-name CN=o365vm.example.co.uk,OU=I.T.,O=Example,L=Hillsborough,ST=Down,C=GB

revocation-check crl

rsakeypair o365rsakeys

!

o365vm(config)#crypto pki authenticate o365trustpoint - "gdig2.crt" goes here

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

MIIE0DCCA7igAwIBAgIBBzANBgkq……..

-----END CERTIFICATE-----

quit

Certificate has the following attributes:

Fingerprint MD5: 96C25031 BC0DC35C FBA72373 1E1B4140

Fingerprint SHA1: 27AC9369 FAF25207 BB2627CE FACCBE4E F9C319B8

Certificate validated - Signed by existing trustpoint CA certificate.

Trustpoint CA certificate accepted.

% Certificate successfully imported

o365vm(config)#crypto pki import o365trustpoint certificate - "b42a158d61851696.crt" goes here

Enter the base 64 encoded certificate.

End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

MIIFRTCCBC2gAwIBAgIJALQqFY1h……..

-----END CERTIFICATE-----

quit

% Router Certificate successfully imported

GoDaddy root certificate is imported into this trustpoint - root cert name is "Go Daddy Root Certificate Authority - G2"

crypto pki trustpoint GoDaddyRoot

enrollment terminal

revocation-check none

!

GoDaddy bundle (intermediate cert chain) certificate is imported into this trustpoint - chain from"gd_bundle-g2-g1.crt"

crypto pki trustpoint GoDaddyBundle

enrollment terminal

chain-validation continue GoDaddyRoot

revocation-check none

!

GoDaddy intermediate cert and GoDaddy signed cert are imported into this trustpoint - "gdig2.crt" - "b42a158d61851696.crt"

crypto pki trustpoint GoDaddyCert

enrollment terminal

chain-validation continue GoDaddyBundle

revocation-check crl

rsakeypair o365rsakeys

!

The geotrust contains the "Baltimore CyberTrust Root"– TLS handshake won’t work without the servers root cert!!

crypto pki trustpoint geotrust

enrollment terminal pem

revocation-check none

!

This is your certificate chains after they have been enrolled - long chains omitted below

crypto pki certificate chain o365trustpoint

certificate ca 00B42A158D61851696
30820545 3082042D A0030201 02020900 B42A158D 61851696 300D0609 2A864886

certificate ca 07
308204D0 308203B8 A0030201 02020107 300D0609 2A864886 F70D0101 0B050030

crypto pki certificate chain GoDaddyRoot

certificate ca 07

308204D0 308203B8 A0030201 02020107 300D0609 2A864886 F70D0101 0B050030

quit

quit
crypto pki certificate chain GoDaddyCert

certificate ca 00B42A158D61851696
30820545 3082042D A0030201 02020900 B42A158D 61851696 300D0609 2A864886

certificate ca 07
308204D0 308203B8 A0030201 02020107 300D0609 2A864886 F70D0101 0B050030

quit

crypto pki certificate chain GoDaddyBundle

certificate ca 07

308204D0 308203B8 A0030201 02020107 300D0609 2A864886 F70D0101 0B050030

quit

crypto pki certificate chain geotrust

certificate ca 01A5

3082025A 308201C3 020201A5 300D0609 2A864886 F70D0101 04050030 75310B30

quit

!

ip domain name example.co.uk

ip name-server 8.8.8.8

!

This is not essential for o365 - I think it's used to present the go daddy cert to a client if CUBE were to act as a server

no ip http server

ip http secure-server

ip http secure-trustpoint GoDaddyCert

This is your sip-ua configuration

!

sip-ua

crypto signaling default trustpoint o365trustpoint

!

o365vm#show sip-ua connections tcp tls brief

Total active connections : 1

-------------------------------------------------------------------------------------------------------------------

Some helpful links

https://learningnetwork.cisco.com/thread/49964 - detailed TLS handshake

https://supportforums.cisco.com/document/13126691/configure-sip-tls-using-ca-signed-certificates-between-call-manager-and-cube

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/unified-access/cube-asr-release-10-0.pdf - cucm 10.5 to o365 configuration guide - poor on the IOS side though

Another thing to note - TLS doesn't work with NAT - once messages are encrypted the firewall can no longer modify the from fields, so when the far end receives an invite it will see the LAN address instead of the public and will have no route back to your server/GW.

Hope this helps and saves you some time!

Tags; SIP, TLS, SERVER, CLIENT, O365, Office365, GoDaddy, CSR, Baltimore, Root, Certificates,

watson.graeme · ‎04-26-2017

Hi Oleg

Thanks for your update. I am basically trying to replicate your setup using the GoDaddy certs.

crypto pki trustpoint o365trustpoint
enrollment terminal
fqdn o365***.***.com
subject-name CN=o365***.***.com,OU=***,O=***,L=London,ST=England,C=GB
revocation-check crl
rsakeypair o365rsakeys
!
crypto pki trustpoint GoDaddyRoot
enrollment terminal
revocation-check none
!
crypto pki trustpoint GoDaddyBundle
enrollment terminal
chain-validation continue GoDaddyRoot
revocation-check none
!
crypto pki trustpoint GoDaddyCert
enrollment terminal
subject-name CN=o365***.***.com,OU=***,O=***,L=London,ST=England,C=GB
chain-validation continue GoDaddyBundle
revocation-check crl
rsakeypair o365rsakeys
!

When I try to import the router cert I get the following error:

o365***(config)#crypto pki trustpoint GoDaddyCert
o365***(ca-trustpoint)#crypto ca import GoDaddyCert certificate
% You must authenticate the Certificate Authority before
you can import the router's certificate.

I have imported and imported the goDaddy root and intermediate certs ok.

Any ideas?

Thanks

Graeme

Oleg Serstjuk · ‎04-26-2017

Hi Graeme,

I edited my original post, I made a mistake and had to open TAC case.

I dont think we need the GoDaddyCert trustpoint we can just use the o365trustpoint instead

The correct way to import a CA signed cert is first to "authenticate" the intermediate cert of the CA and then "import" the signed certificate

o365vm(config)#crypto pki authenticate o365trustpoint

Enter the base 64 encoded CA certificate.

End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

MIIE0DCCA7igAwIBAgIBBzANBgkq……..

-----END CERTIFICATE-----

quit

Certificate has the following attributes:

Fingerprint MD5: 96C25031 BC0DC35C FBA72373 1E1B4140

Fingerprint SHA1: 27AC9369 FAF25207 BB2627CE FACCBE4E F9C319B8

Certificate validated - Signed by existing trustpoint CA certificate.

Trustpoint CA certificate accepted.

% Certificate successfully imported

o365vm(config)#crypto pki import o365trustpoint certificate

Enter the base 64 encoded certificate.

End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

MIIFRTCCBC2gAwIBAgIJALQqFY1h……..

-----END CERTIFICATE-----

quit

% Router Certificate successfully imported

We have this working now and I think all config that is needed to make this work is below

crypto pki trustpoint o365trustpoint

enrollment terminal pem

fqdn o365vm.example.co.uk

subject-name CN=o365vm.example.co.uk,OU=I.T.,O=Example,L=Hillsborough,ST=Down,C=GB

revocation-check crl

rsakeypair o365rsakeys

!

crypto pki trustpoint GoDaddyRoot

enrollment terminal

revocation-check none

!

crypto pki trustpoint geotrust

enrollment terminal pem

revocation-check none

!

ip domain name example.co.uk

ip name-server 8.8.8.8

!

sip-ua

crypto signaling default trustpoint o365trustpoint