This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software: Code Composer Studio
Hello,
I have the exact same issue as originally reported below. The issue is prevalent in both Linux and Windows versions of CCS v8. Please let me know if progress has been made.
Thank you
-Russell
Hello,
with the newest CCS v8.0.0 I cannot access the Code Generation Tool Update Site anymore. With CCS 6.1.2 and CCS 7.4.0 the identical site works perfectly:
This is what I get with v8
Unable to read repository at software-dl.ti.com/.../content.jar.
Unable to read repository at software-dl.ti.com/.../content.jar.
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Hi Ki,
To answer your questions
1. Prior versions work on the corporate network. (still work right now)
2. Some sites work while others don't.
Here are some that do NOT work
"http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2linux/content.jar "
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/content.xml.xz
"software-dl.ti.com/.../content.jar"
"http://software-dl.ti.com/ccs/esd/device_support_auto/content.jar"
"http://software-dl.ti.com/ccs/esd/device_support_radar/content.jar"
"http://software-dl.ti.com/ccs/esd/device_support_sitara/content.jar"
"software-dl.ti.com/.../content.jar"
Here is one that does work:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/gcc/Updates/win32
I hope this help narrows things down for you
Thank you for your help
-Russell
I think I've figured out what's going on.
TI's web server will redirect the request for the update site differently depending on the user agent.
When running CCS 7.4 it redirects you to the file via http:
GET /dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/p2.index HTTP/1.1 User-Agent: p2/mars-sr0 (Java 1.8.0_112-b15 Oracle Corporation; Windows7 6.1.0 x86; en_US) com.ti.ccstudio.branding.product/4.6.0.I20160606-1100 (org.eclipse.ui.ide.workbench) Host: software-dl.ti.com HTTP/1.1 301 Moved Permanently Location: http://downloads.ti.com/dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/p2.index GET /dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/p2.index HTTP/1.1 User-Agent: p2/mars-sr0 (Java 1.8.0_112-b15 Oracle Corporation; Windows7 6.1.0 x86; en_US) com.ti.ccstudio.branding.product/4.6.0.I20160606-1100 (org.eclipse.ui.ide.workbench) Host: downloads.ti.com HTTP/1.1 200 OK
When running CCS 8 it redirects you to a https url:
GET /dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/p2.index HTTP/1.1 User-Agent: p2/1.1.300.v20161004-0244 (Java 1.8.0_112-b15 Oracle Corporation; Windows7 6.1.0 x86; en_US) com.ti.ccstudio.branding.product/4.7.1.M20171009-0410 (org.eclipse.ui.ide.workbench) Host: software-dl.ti.com HTTP/1.1 302 Moved Temporarily Location: https://www.ti.com/general/docs/licreg/anonymousproddownload.tsp?downloadPage=true&location=http://software-dl.ti.com/dsps/dsps_public_sw/sdo_ccstudio/codegen/Updates/p2win32/p2.index
(Both edited for conciseness. Use Wireshark filter "http or ssl.handshake or ssl.alert_message")
CCS 8 then begins to open a https connection, but sends a certificate unknown alert and hangs up. The server only sent its certificate and did not include the intermediate certificates that chain in back to a trusted root like it should have.
As a temporarily workaround, I added the appropriate intermediate CA as a trusted root.
$ cd /c/ti/ccsv8/eclipse/jre/lib/security/ $ cp cacerts cacerts.orig $ ../../bin/keytool.exe -import -alias tempworkaround -keystore cacerts -file the_certificate.crt Enter keystore password: changeit ... Trust this certificate? [no]: yes Certificate was added to keystore
After doing that the updater worked properly. Once I installed the compiler I needed, I undid my workaround and it still worked for some reason. I tried a bunch of things but couldn't get it to break again. Today, I noticed that the server was sending a different certificate and was properly including the intermediate certificate. If that changed happened while I was working on this, it would explain why it kept working once I undid the workaround, but I think I would have noticed. Unfortunately I didn't save the packet captures so I can't say for sure.
In summary, some of TI's servers had broken SSL. It appears to have been fixed.