• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

Hi,

 

I know that SoundPoint is basicalluy dead, but we have a lot of these out there and want to improve security.  So far we are unable to get mutual TLS authentication to work with self-signed certificates.  (We've gotten mutual TLS to work flawlessly with other major vendor IP phones).  Polycom is the last hold-out.

 

We're trying to get the following setup to work:

 

Firmware 4.0.14.0987

Self-Signed Certificate with Self-Signed CA

Mutual TLS Authentication (Only accept signed certificates from polycom phones)

 

We first provision the polycom (IP-335/550/650/etc/etc) with HTTP and use <device> to set up for HTTPS

 

<device
device.set="1"
device.net.etherVlanFilter.set="1" device.net.etherVlanFilter="1"
device.dhcp.bootSrvUseOpt.set="1" device.dhcp.bootSrvUseOpt="2"
device.dhcp.bootSrvOpt.set="1" device.dhcp.bootSrvOpt="166"
device.dhcp.bootSrvOptType.set="1" device.dhcp.bootSrvOptType="String"
device.prov.serverType.set="1" device.prov.serverType="HTTPS"
device.prov.serverName.set="1" device.prov.serverName="provisioning-server-here">

<device.sec
device.sec.TLS.customCaCert1.set="1" device.sec.TLS.customCaCert1="-----BEGIN CERTIFICATE-----
certificate-goes-here
-----END CERTIFICATE-----"
/>
</device>

 

So far, this acomplishes turning off future usage of option 66 (and use option 166 if we want to re-program in the future).  So now the polycom phone successfully will download the above xml via HTTP, and then it will TRY to connect to HTTPS but not succeed.

 

Flow:

The Polycom downloads the above XML via HTTP and does initial provisioning.  The polycom then reboots itself and then continually tries https conneection, but handshake always fails.

 

Here's the log from the polycom:

 

000015.462|so |*|03|Network initialized. Starting network tasks.
000015.464|log |*|03|Install file upload callback for 'so'

0723102804|cfg |5|03|Prm|Parameter acd.reg requested type 0 but is of type 2
0723102804|sip |*|03|Fast Boot Measurement Point: Ready for Call, uptime: 15.616 sec.
0723102804|app1 |*|03|Ctx [0] Registered [false]
0723102804|app1 |5|03|Corporate directory instance does not exists.
0723102806|copy |4|03|SSL_connect error SSL connect error.error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
0723102808|copy |4|03|SSL_connect error SSL connect error.error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
0723102810|copy |4|03|SSL_connect error SSL connect error.error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca

Why would the phone not recognize the CA?  When viewing the fingerprint of the CA in the polycom phone web portal, it matches the server.

 

We have VERIFIED that the polycom DOES trust the CA, because If we turn OFF requred client certificates at the HTTPS server (Apache 2.x) , the polycom SUCCESSFULLY downloads configuration from HTTPS (so obviously the phone can accept the self-signed certificate and connect to a self-signed server).

 

When we turn on debugging on apache, we clearly see the polycom is not sending the device certificate when connecting to the https server, and the phone is giving up the connection PRIOR to any attempt at sending the device certificate for client-cert-authentication.

 

Final Questions:

Does mutual TLS only work with officially signed certificates?  Ie. verisign, starfield, etc?

Does mutual TLS work at all on a Polycom Sountpoint?

6 REPLIES 6
HP Recommended

Have you read this?

 

https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-documents/en...

 

Any modern 4.x soundpoint ought to just have an embedded polycom cert from the factory. Simply using the Polycom CA and the embedded certs is going to significantly reduce the complexity of what you're trying to do.

HP Recommended

@jnl06 wrote:

Have you read this?

 

https://support.polycom.com/content/dam/polycom-support/products/voice/polycom-uc/other-documents/en...

 

Any modern 4.x soundpoint ought to just have an embedded polycom cert from the factory. Simply using the Polycom CA and the embedded certs is going to significantly reduce the complexity of what you're trying to do.


 

Hi,

 

Thaks for the response!  Yes, I've gone through this many times... and this is exactly what I'm doing.  Step by step.

 

HTTP server for pushing initial config and self-signed certificate

HTTPS server for pushing credentials to the phone (only accepts Polycom Signed Certificates)

Push Option 66 to point to HTTP server

HTTP server redirects phone to the HTTPS server

Polycom Refuses to negotiate TLS with the HTTPS server

 

Configs:

DHCP Option 66: option tftp-server-name "http://cfg.company.com"

 

Polycom mac.cfg

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

<APPLICATION APP_FILE_PATH="sip.ld" CONFIG_FILES="siteHTTPS.cfg, sip.cfg"
MISC_FILES=""
LOG_FILE_DIRECTORY="Logs"
OVERRIDES_DIRECTORY="Overrides"
CONTACTS_DIRECTORY="Contacts"/>

 

Polycom sip.cfg

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

Standard config from Configs/sip-interop.cfg

 

Polycom siteHTTPS.cfg

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

<polycomConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="polycomConfig.xsd">

<device> xml chunk from my initial post... device.sec.TLS.customCaCert1= self signed certificate for provision.company.com

</polycomConfig>

 

Apache Config:

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

# Make sure ONLY validated can connect!

 

# All certs from Polycom PKI (pki.polycom.com - /pki/

SSLCertificateChainFile "/etc/ssl/private/provision-client.bundle-chain.pem"  

 

# Two Polycom Equipment Certs from pki.polycom.com/pki
SSLCACertificateFile "/etc/ssl/private/polycom-equipment.pem"


SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars +ExportCertData

 

 

And that's it!

 

As mentioned, the polycom refuses to connect to the HTTPS server when SSLVerifyClient is enabled (the phone does not send the certificate to the server in the TLS negotiation, it bails prior to that).

 

When SSLVerifyClient is in use, the polycom outputs this to the logs:

0723102810|copy |4|03|SSL_connect error SSL connect error.error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca

 

Am I missing something?

 

Why does the phone all of a sudden not trust the CA?

 

When SSLVerifyClient is not in use, the Polycom CAN provision on HTTPS, it just does not provide a client certificate for device authentication

HP Recommended

The option 66 line should say provision.company.com.  

 

Baically everything matches everything else as far as urls/certificates/etc

HP Recommended

Ok I think there's a couple pieces of confusion here.

 

You don't NEED self-signed certificates if you are using Polycom's PKI. Its one or the other. The phones have embedded polycom certificates unless they're 10+ years old.

 

Your certificate chain file should be the ca-bundle for whomever provides the SSL certificate for your web server.

 

The SSL certificate appears to be trusted, so you're failing in the authentication piece, which is ENTIRELY separate from the SSL transport layer, basically.

 

Here's my relevant pieces of apache configuration. Note that my combined.crt contains the CA certs for both Yealink and Polycom, as we provision both from a single URL.

 

SSLCACertificateFile /etc/httpd/ssl/combined.crt

SSLVerifyClient require

SSLVerifyDepth 3

 

 

Additionally the documentation indicates that the certificate should be specified as a URI to a pem-encoded file, not actually embedding the cert into the config as you are attempting. But I've never tried to do my own PKI.

HP Recommended

@jnl06 wrote:

 

You don't NEED self-signed certificates if you are using Polycom's PKI. Its one or the other. The phones have embedded polycom certificates unless they're 10+ years old.

 


 

I think there is a point of view/perspective issue here.  I'm using both self-signed and PKI but not in the way you are describing.

 

You cannot use polycom pki for the web server ssl-certificate because for obvious reasons they do not publish the private keys to their pki certificates.  You can however use polycom pki to validate client certificates in the way that you do, and the way that I'm attempting (albiet with a self-signed server cert).

 

You need to either self-sign a web server ssl certificate, or buy one.

 

I'm not generating a self-signed certificate for the phone to use as authentication... my server is using a self-signed certificate (ie: I did not buy an ssl cert from verisign/godaddy etc).  So therefore I don't need a certificate chain for who signed my certificate, since *I* self-signed it.

 

I was playing around with the ca certificate chain thinking it may help with the client authentication by loading the polycom chain, but that hasn't worked so far.

 

And yes, I am attempting to use polycom PKI for authentication and this is where it breaks down.  The polycom phone does not trust the ssl web server when the web server requires a client certificate (ie: when the server returns ERR_BAD_SSL_CLIENT_AUTH_CERT or similar, the device is then supposed to provide the cert... which it does not) which is entirely prior to the mutual tls authentication (authentication using the client certificate pre-loaded by the factory on the phone).

 

 

I think the final thing to test here, is to actually bite the bullet and buy an officially signed SSL Cert, because until someone chimes in that this is not the case, or I actually get a chance to test this... I still believe that problem that is occuring here is that if client auth is required, the phone does not trust the self-signed web server certificate.  And I'm coming up with this hypothesis based on the fact the phone DOES trust the web server ssl certificate if client-auth is OFF.  And I believe I've elimited issues with my specific setup, because yealink will authenticate just fine with my self-signed ssl server certificate and SSLVerifyClient require.

 

 


@jnl06 wrote:

 

Additionally the documentation indicates that the certificate should be specified as a URI to a pem-encoded file, not actually embedding the cert into the config as you are attempting. But I've never tried to do my own PKI.


 

Ah... I've always uses an embedded ssl cert and this has always worked fine for web server setups that don't require client authentication... but, since this setup works for you I'll try this with a url instead.

HP Recommended

"Ah... I've always uses an embedded ssl cert and this has always worked fine for web server setups that don't require client authentication... but, since this setup works for you I'll try this with a url instead."

 

Did you ever get Soundpoint MTLS working? If so, what did you do?

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.