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
Some useful debugging commands below incase of issues.
debug ccsip messages debug ccsip error
debug ssl openssl errors
debug ssl openssl msg
debug ssl openssl states
1. Generate a 2048 bit key
2. Create the trustpoint, the CN name in the subject-name field must match what is in the Office365 config, as per
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:
% 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-----
-----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 ca authenticate root
crypto pki trustpoint intermediate-primary
chain-validation continue root
crypto ca authenticate intermediate-primary
crypto ca authenticate intermediate-secondary
! 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
crypto pki trustpoint geotrust
!! Import the Geotrust Root certificate
! File from https://www.cybertrust.ne.jp/SureServer/file/root_ca/BCTRoot.txt
Crypto ca authenticate geotrust
! Configure HTTP to use the trustpoint
Check the Digicert keys are valid, you may need to add fw rules to allow access
Hope the above helps or points you in the right direction.
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.
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
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
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.
% 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
GoDaddy bundle (intermediate cert chain) certificate is imported into this trustpoint - chain from"gd_bundle-g2-g1.crt"
crypto pki trustpoint GoDaddyBundle
chain-validation continue GoDaddyRoot
GoDaddy intermediate cert and GoDaddy signed cert are imported into this trustpoint - "gdig2.crt" - "b42a158d61851696.crt"
crypto pki trustpoint GoDaddyCert
chain-validation continue GoDaddyBundle
The geotrust contains the "Baltimore CyberTrust Root"– TLS handshake won’t work without the servers root cert!!
crypto pki trustpoint geotrust
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
quitcrypto pki certificate chain GoDaddyCert
crypto pki certificate chain GoDaddyBundle
crypto pki certificate chain geotrust
certificate ca 01A5
3082025A 308201C3 020201A5 300D0609 2A864886 F70D0101 04050030 75310B30
ip domain name example.co.uk
ip name-server 220.127.116.11
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
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
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,
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.
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
o365vm(config)#crypto pki import o365trustpoint certificate
We have this working now and I think all config that is needed to make this work is below