Common testing issues with TR-069 and SSL
Here are solutions to a few common TR-069 SSL-related issues:
The ACS certificate file specified by the acsCertPath testvar must contain both the certificate and corresponding private key in order for CDRouter’s ACS to use it to establish SSL connections with the CPE. Note that the certificate must be in PEM format and the private key must not be encrypted. For more details on the proper certificate file format, please see the following Knowledge Base article: “How do I use my own (self-signed) certificates with CDRouter’s ACS?”
Some CPE devices will not validate a SSL certificate from the ACS until a time source is established. TR-069 states that devices should skip date validation of certificates if a time source is not established. However, in practice some CPE devices simple end the SSL connection. A common symptom of this problem are DNS requests to an NTP server which is not configured. To alleviate this problem, simply configure the NTP server that is being requested by the CPE:
testvar ntpServer1 18.104.22.168 testvar ntpServerName1 myNTPserver.com
Note that you may configure additional NTP servers if needed.
Typically in SSL based configurations the CPE should be configured with an ACS URL using a domain name instead of an IP address. This allows the CPE to validate that the ACS URL matches the common name in the SSL certificate for the ACS.
By default, the SSL certificate for CDRouter’s ACS uses the common
name acs.cdroutertest.com. In addition, CDRouter automatically maps the
domain name acs.cdroutertest.com to the acsIp
address (22.214.171.124 by
default). If the CPE is using strict validation then the common name
in the certificate from the ACS must match the ACS URL configured on
the CPE. If the CPE is using a hard coded IP address
http://126.96.36.199) instead of a domain name (
for the ACS URL, this check will fail. A symptom of this problem is
the lack of DNS lookups for acs.cdroutertest.com in the log files which
indicates that the CPE is using a hard coded IP address. The
solution to this problem is to configure the ACS URL on the CPE to
http://acs.cdroutertest.com (or another domain name).
Note that if a domain name other than
http://acs.cdroutertest.com is configured
on the CPE, a DNS entry MUST also be added to the CDRouter
testvar dnsHostname1 acs.mydomainname.com testvar dnsIp1 188.8.131.52
CDRouter’s ACS server certificate is signed by an Intermediate CA (Certificate Authority), creating a validation chain ending with the Root CA that is known and trusted by the CPE. By default, CDRouter’s ACS only sends its own server certificate to the CPE when negotiating an SSL/TLS connection with the CPE.
In most cases, the CPE should already have any Intermediate CA certificates needed to validate the ACS, but some CPE’s require the ACS to send them explicitly. In this case, uncommenting the acsCaCertPath testvar will tell CDRouter to transmit all Intermediate CA certificates during the SSL/TLS handshake process.
When using alternate or self-signed certificates, acsCertPath should specify a file containing the ACS server certificate and its corresponding private key (unencrypted) Any Intermediate CA certificates needed to validate the server certificate should all be placed together in a file specified by the acsCaCertPath testvar.
In order for the CPE to validate the ACS SSL certificate, the root CA for the CDRouter ACS must be installed on the CPE. If the root CA is not installed, the CPE will reject the SSL connection. The solution to this problem is to install the root CA or disable certificate verification. Information about the root CA can be found here:
Note that you may also use your own server certificates using the following testvars:
testvar acsCertPath /usr/cdrouter/tests/acs.cdroutertest.com.pem testvar acsCaCertPath /usr/cdrouter/tests/acs.cdroutertest.com-ca.pem