Need signed certificate for secure provisioning SPA 500 series phones

[dogatemycomputer]

Greetings,

We are an ITSP who offers customers free or reduced cost phones with contract.   We move about 4000 phones/year and we are on target to move approximately 6000 phones during 2014.  

The phones must be securely locked to protect against tampering and theft.  Honestly we find Cisco's support to be so poor we have opted for better quality products such as Grandstream and Polycom that include this service and support out of the box.

Since we need a Cisco signed certificiate to accomplish secure provisioning we decided to RTFM.   This manual says to send our CSR to certadmin@cisco.com but the bounce back message has determined this to be a lie.  

http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpipp/ip_phones/administration/guide/spa500_admin.pdf

Do not be concerned.   We are not heartbroken over your rejection.  In fact it was refreshing to know Cisco's poor product quality and abysmal documentation is worth exactly what you pay your investors: $0.06 every quarter.  In fact we are still trying to understand how you managed to sell Linksys to Belkin. In any case if you would like some help propping up your stock price then we are interested in offering your SPA series phones to our customers.  Of course judging by the poor quality of the support so far..  we doubt that is going to happen. 

Please feel free to surprise us.   We would like a valid, working Cisco email address or phone number that routes to a live, breathing human being who can get us the certificate we require.  Please keep in mind we are here to sell your products.  We are not interested in paying Cisco for a "service contract", spending days in your massive IVR system or trudge through the depths of h*ll so we may kneel and worship before the all-mighty Cisco.   We understand, for the moment, you are a large, multi-national corporation who couldn't care less about our company.  Of course all giants fall when they stop caring about their customers.  Just ask RIM how that worked out for them. 

Thank you and have a good day.

[Dan Lukes · Accepted solution]

Since we need a Cisco signed certificiate to accomplish secure provisioning we decided to RTFM.   This manual says to send our CSR to certadmin@cisco.com but the bounce back message has determined this to be a lie.   
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpipp/ip_phones/administration/guide/spa500_admin.pdf

The relevant paragraph from document you referenced above:

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

Contact a Cisco support person who will work with you on the certificate process.

If you are not working with a specific support person, you can email your request

to ciscosb-certadmin@cisco.com

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

Note the email address in documentation - it's not the one you used. You need not only read the manual but also follow the instructions.

It's not so suprising the email sent to incorrect address has been rejected. Althougth there are many good reason to bark to Cisco, this one seems not to be one of them.

Dont forget the first sentence of paragraph. Ask Cisco representative in your country before you will sent email directly or your direct email request may be rejected.

[dogatemycomputer]

Your answer was correct.  The email address was mis-spelled.  

Of course if the first address provided by a Cisco rep was correct (linksys-certadmin@cisco.com) or we were not told we needed a Service Contract just to obtain support when trying to open a case on this issue then our post would have been of a different nature. 

I still fail to understand why this kind of security is required and not optional.  We have a public/private key infrastructure already in place to confirm a server belongs to a domain.  If our certificiate expires or is not present when a Grandstream or Polycom phone attempts to provision then it will simply refuse the config file and continue booting.  Why does Cisco require a seperate certificate?

If someone goes to the lengths required to impersonate the public/private key infrastructure necessary to bypass secure provisioning then I do not believe a Cisco issued ceritificate will be useful. 

[Dan Lukes]

I still fail to understand why this kind of security is required and not optional.  We have a public/private key infrastructure already in place to confirm a server belongs to a domain.  If our certificiate expires or is not present when a Grandstream or Polycom phone attempts to provision then it will simply refuse the config file and continue booting.  Why does Cisco require a seperate certificate?

It seems I didn't understood your problem in full. I see nothing non-optional here.

1. You may decide not to use certificate authentication at all. You may use plain http with no certificate. Even in such case you can send encrypted configuration to phone, so privacy is maintained. No place for certificate issued by Cisco here.
2. If you decide to authenticate using certificate, you can order phone to accept any certificate authority you decided to trust. No place for certificate issued by Cisco here as well, you will use certificates issued by CA according your wishes.
3. There is Cisco's CA configured in device by default. You may decide to trust it. In such case, you need certificate issued by such authority, of course. It's the only case you need certificate issued by Cisco, but it's result of your decision.

In short, it's up to you to decide which CA you want to use, or you may not use certificates at all. I see nothing mandatory here.

If our certificiate expires or is not present when a Grandstream or Polycom phone attempts to provision then it will simply refuse the config file and continue booting.

My SPA50x will continue with current configuration if no new configuration can be loaded from provisioning server. Unfortunately, your original description is focused to emotions rather than facts, so it's hard to guees what kind of problem you have with it.

Why does Cisco require a seperate certificate?

IMHO, it doesn't require it. Unless you configuration force such kind of requirements.

[dogatemycomputer]

This posting was in the context of Secure Provisioning.   Using TFTP or HTTP is insecure and therefore belongs in a different post.

Cisco absolutely requires a Cisco certification for secure provisioning.

To use HTTPS with Cisco IP phones, you must generate a Certificate Signing 
Request (CSR) and submit it to Cisco. The Cisco IP phone generates a certificate 
for installation on the provisioning server that is accepted by Cisco IP phones 
when they seek to establish an HTTPS connection with the provisioning serve

The first thing the SPA series phones do when connecting to the server is look for a Cisco certificate.  If the certificiate is missing or invalid then the phone will abandon the handshake and not even attempt to download the firmware or configuration files.  

Each secure provisioning server is issued an secure sockets layer (SSL) server 
certificate, directly signed by Cisco. The firmware running on the Cisco IP phone 
clients recognizes only these certificates as valid. The clients try to authenticate 
the server certificate when connecting via HTTPS, and reject any server 
certificate not signed by Cisco.

Grandstream and Polycom will begin the same handshake when contacting the provision server but instead will verify the SSL certificate belongs to the FQDN specified in the PROFILE RULE.   These phones do not require a seperate certificate from either Grandstream or Polycom to complete the authentication and download process.

As an example..  Lets assume our provision server is named "https://provision.phonecompany.com".   Our Grandstream equipment is configured with the CONFIG SERVER PATH of "https://provision.phonecompany.com".   The "HTTPS" tells our Grandstream equipment to check "https://provision.phonecompany.com" contains a valid SSL certificate for *.phonecompany.com and it is not expired.   If the SSL certificiate is valid then the Grandstream phone will download the configuration file and proceed.

However..  If you are attempting to unlock one of our phones this process will fail.   The phone will connect to your internal IIS server (which you spoofed the phone into believing is "https://provision.phonecompany.com") but the download will fail because the public SSL certificiate provided your internal IIS server will not be valid for "https://provision.phonecompany.com".

[Dan Lukes]

Security is no "magic word" - you are asking security against some kind of attack. You didn't described your requirements.  It seems you don't know attributes of other method of provisioning  nor you evaluated them against your requirements. You just selected so  called "secure provisioning" method because of it's name, not  attributes. There may be solution fulfilling your needs, but you are not interested to found as they are not called "secure provisioning" in documentation.

Well, It seems my skills are definitely not sufficient to help you. Sorry. May be someone else.

However..  If you are attempting to unlock one of our phones this process will fail.   The phone will connect to your internal IIS server (which you spoofed the phone into believing is "https://provision.phonecompany.com") but the download will fail because the public SSL certificiate provided your internal IIS server will not be valid for "https://provision.phonecompany.com". 

Are you sure you  understand how the authentication based on X509 certificates is working? Your mistake can be explained by simple demonstration rather than long explanation,

• Send me CSR (certificate request) for provision.phonecompany.com
• I will sign it by my own CA. It's free. Resulting certificate I will it back to you
• Install it on your HTTP server.

OR

• just install the key and certificate attached to this message. It's valid for next 60 days. The transport passphrase is aaaa

Now you have HTTPS server with valid SSL certificate for provision.phonecompany.com

Cheat the Grandstream phone to connect to your server (believing it is provision.phonecompany.com HTTPS server). It will either:

1. accept configuration
2. reject it because the certificate is not issued by CA trusted by Grandstream phone

In the case (1) - where is a security (not speaking about method name) ? Unless you check the issuer, checking of the name is useless. Anyone can issue certificate with any name. Even I can do it - see attachment.

In the case (2) - only those certificates issued by preselected (trusted) set of CA are accepted. I'm almost sure it's Grandstream's way. It's the way of Cisco phone as well althougth the list of trusted CA is not the same. It is secure way, despite you hate it. May be you need no such kind of security - I don't know. You didn't specified the goal, so it's hard to search for solution.

[ws]

I totaly agree with dogatemycomputer.

If I like to authenticate the client - fine. I need to verify.

If I like to authenticate the server - why does Cisco need to sign the cert? Just put a list of trusted CA into the firmware like any linux does. And update that with new firmware loads.

We also just want to secure the connection with https. Nothing more, nothing less.

So pls stop bashing around here and accept a valid official signed SSL Cert from the Server!

br

Walter

[Dan Lukes]

Booth direction works the same way. Either side considers other side authenticated if certificate presented by side A has been issued by authority considered trusted by side B. That's all.

Your different conclusion for each direction mean you misunderstood SSL basics. We can discuss either conclusion, but not both at the same time.

like any linux does

The configuration you are referring is DEFAULT configuration not SECURE configuration. No, it's not the same.

[ws]

Not helpful.

[Dan Lukes]

You didn't asked for help. You just described a solution of unknown issue you have. Moreover, the described solution seems not to be generally secure.

Describe what you are trying to do, describe issue you have - and be sure someone will try to help you. Better to create new thread for new issue ...

[ws]

Hi!

The initial request was to just make a HTTPS connection to a provisioning server. This is what most people deploying SPAs want to have.
The need for client authentication based on X.509 is a 2nd step, probably not needed. Just securing the connection for transport with some sort of authentication (I could describe some measure here but this is off topic).
Any PC can do https://some.host because it knows the trusted CAs. This is what we also want a SPA should be able to do.
So the server can be trusted. Period. To identify the SPA is a 2nd step. But this has nothing to do with the stupid requirement of a Cisco signed provisioning server certificate!

Br
Walter

[Dan Lukes]

HTTPS connection to server is solution of particular issue. The issue in question is "security". Phone should NOT load configuration from any server running https, configuration needs to be loaded from server dedicated to serve provisioning file.

It mean - server needs to be authenticated. What "authenticated" mean in the SSL universe ? It mean the certificate of server has been issued by trusted certification authority.

What authorities you trust ? No one knows but you. It's why you need to import certificate of your choice to phone's trusted store. It make such CA trusted, it allow it to issue certificate recognized trusted to your provisioning server, it allow your phone to be configured secure way. That's all.

Any PC can do https://some.host because it knows the trusted CAs.

Sorry, neither PC nor operating system vendor nor browser vendor knows what CA are trusted by you.

Are you accepting a list of authorities you know nothing about just because someone (you know almost nothing of about) has preinstalled them on your computer ? It's your sovereign decision, but you almost gave up on security. Assuming your conclusion are not based of misunderstanding of X509 trust concept ...

The solution you described is technically possible, but it have nothing to do with secure provisioning. It's why I feel confused - this thread is dedicated to secure provisioning, while you are trying to promote solution based on identity verified by unknown entity designated to the role by unknown entity.

client authentication based on X.509 is a 2nd step, probably not needed.

It depends. Provisioning may contain sensitive information - like passwords (SIP account, WWW UI, ...). You need not to disclose passwords just because he requested provisioning file. To maintain security you need a kind of client authentication. Secure provisioning mean not only a rogue user is unable to push unauthorized configuration into phone, it also mean sensitive parts of configuration are not leaking to unauthorized device/user.

[ws]

Still there is no need for Cisco signed Certificate. This does not help anyone.
It's a pitty that especially those ATAs are easily available and just work. Otherwise we would have gone for another CPE for a long time.
You know what happens? Everybody is falling back to http. Great job.
Well: It wouldn't be a problem if it wouldn't be so difficult to get a signed cert. Whom should I contact? Amazon that sells those CPEs?
Br
Walter

[Dan Lukes]

Still there is no need for Cisco signed Certificate.

True. There's no need for Cisco signed Certificate.That's has tried to explain.

So I still don't understand your issue. Use certificate issued by yours preferred authority.

Everybody is falling back to http.

Even I can misuse word "everybody" to support arguments. It doesn't turn weak argument into fact.

Everybody wishing for secure provisioning is using HTTPS properly - with server using either Cisco certificate or certificate issued by other authority.

I will not participate in flame. If you have a issue, I will spent my spare time for free in attempt to discover a solution for you. Security is just word. If you wish to discuss details, we need to enumerate risks you wish to avoid first. Otherwise we can't decide the particular countermeasure is effective or not.

It wouldn't be a problem if it wouldn't be so difficult to get a signed cert. Whom should I contact? Amazon that sells those CPEs?

At the first, you need not certificate signed by Cisco in most scenarios. Just for the purpose of this discussion, I will assume you need it - but remember, most scenarios require no such cert (any certificate is enough) so respond for self, not on behalf of "everyone"

At the second, Amazon is seller with no support of products sold. I may ask why you bough product from someone not fulfilling your requirements, but I will not ask it. You selected wrong supplier for your particular project - it may happen.

You asked "where to obtain Cisco certificate" in 5th post. Not in first, not in second, even not in fourth. Did you called Cisco support ? If not, why not ?

Note that this forum is NOT Cisco support. This is community project. You are discussing here with volunteers and enthusiasts.  

I'm maintaining SPAxxx based local networks in about seven countries. I'm ready to share skills. It's very hard to help someone not disclosing the issue details. Nothing you disclosed so far mean you need Cisco issued certificate. It seems you have a requirements you wish not to disclose in public. In such case you should call Cisco support.

[ws]

That's great, if I do not need a Cisco Certificate on the server side. The issue is that the SPA refuses to fetch config from our https provisioning server if I just put https:// in front of the provisioning server instead of http://.
We postponed that migration to https then for a while because we concluded the last time, that such a server certificate is needed (as noted in those documentations referred above). And I understood in the initial post that dogatemycomputer also has the same problem: Where to get this Cert from? Sure we have an official signed cert at the prov server.
If you tell me that this is not really needed I will retry that now.
Br
Walter