https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/RELENG-30 releng <p>Thanh &amp; Co, are you sure that using the https SSL cert on <a href="https://nexus.opendaylight.org" class="external-link" target="_blank" rel="nofollow noopener">https://nexus.opendaylight.org</a> and <a href="https://git.opendaylight.org" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org</a> with StartCom as a CA is a good idea?</p> <p>This is causing PITA issues such as:</p> <p><a href="http://blog2.vorburger.ch/2016/04/how-to-resolve-validatorexception-pkix.html" class="external-link" target="_blank" rel="nofollow noopener">http://blog2.vorburger.ch/2016/04/how-to-resolve-validatorexception-pkix.html</a></p> <p><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014</a></p> <p>Couldn't we just use a https SSL cert on *.opendaylight.org issued/signed by a "more standard" CA whose root cert is part of all Java installations, to avoid people wasting time on issues like above?</p> <p>Operating System: All<br/> Platform: All</p> RELENG-30

https SSL cert by using StartCom as a CA is a PITA

Bug Resolved Cannot Reproduce Unassigned Michael Vorburger Tue, 26 Apr 2016 10:03:35 +0000 Tue, 28 Nov 2017 16:11:05 +0000 Tue, 28 Nov 2017 16:11:05 +0000 unspecified Autorelease 0 3 <p>FTR: This <a href="https://lists.opendaylight.org/pipermail/dev/2016-April/thread.html#1866" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/dev/2016-April/thread.html#1866</a> thread highlights that other users are having similar problems ...</p> <p>(In reply to Michael Vorburger from comment #0)<br/> &gt; Thanh &amp; Co, are you sure that using the https SSL cert on<br/> &gt; <a href="https://nexus.opendaylight.org" class="external-link" target="_blank" rel="nofollow noopener">https://nexus.opendaylight.org</a> and <a href="https://git.opendaylight.org" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org</a> with<br/> &gt; StartCom as a CA is a good idea?<br/> &gt; <br/> &gt; This is causing PITA issues such as:<br/> &gt; <br/> &gt; <a href="http://blog2.vorburger.ch/2016/04/how-to-resolve-validatorexception-pkix.html" class="external-link" target="_blank" rel="nofollow noopener">http://blog2.vorburger.ch/2016/04/how-to-resolve-validatorexception-pkix.html</a><br/> &gt; <br/> &gt; <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014</a><br/> &gt; <br/> &gt; Couldn't we just use a https SSL cert on *.opendaylight.org issued/signed by<br/> &gt; a "more standard" CA whose root cert is part of all Java installations, to<br/> &gt; avoid people wasting time on issues like above?</p> <p>Our Nexus system uses a certificate from COMODO because of issues with JAVA. When we had first moved the system into our private cloud there was a mistake with the setup and had applied our * cert to the system.</p> <p>Gerrit on the other hand, uses our * cert and will continue to do so. StartCom is a "more standard" CA, it's recognized by all browsers and Java installations <em>except</em> for Oracle's Java. As long as you're accessing Gerrit from Java via the SSH (preferred) interface you shouldn't have any issues.</p> <p>We have plans to eventually switch all of our certs to using Let's Encrypt, which is also supported by the Oracle Java, but there is still integration work with our management frameworks that has to happen before that's an option.</p> <p>&gt; StartCom is a "more standard" CA, it's recognized by all browsers and Java installations <em>except</em> for Oracle's Java. </p> <p>Oh OK I didn't realize that this was Oracle Java specific, but OK with Open JDK.. perhaps less of a blocking issue then. Thanks for clarifying, noted.</p> <p>&gt; As long as you're accessing Gerrit from Java via the SSH (preferred) interface you shouldn't have any issues.</p> <p>In <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.eclipse.org/bugs/show_bug.cgi?id=492014</a> I had faced problems accessing Gerrit via <a href="https://www.eclipse.org/egerrit/" class="external-link" target="_blank" rel="nofollow noopener">https://www.eclipse.org/egerrit/</a> which talks https to the Gerrit REST API. </p> <p>The git clone ssh always works fine of course, yes.</p> <p>Andrew &amp; Thanh, just FYI: This <b>IS</b> a PITA - I've just had someone else reach out to me on private IRC DM struggling with this AGAIN. Now it was because that user tried to install yangide from <a href="https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide/snapshot/content.xml" class="external-link" target="_blank" rel="nofollow noopener">https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide/snapshot/content.xml</a> using <a href="https://github.com/vorburger/opendaylight-eclipse-setup" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/vorburger/opendaylight-eclipse-setup</a>, and hit this..</p> <p>Just adding actual error message to be able to find this issue more easily again in the future, it's: "javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=vorburger" class="user-hover" rel="vorburger">vorburger</a> is this still an issue? I haven't heard of SSL issues recently so thinking perhaps this can be closed now. Also I believe we're now using LetsEncrypt.</p> <p>I've not heard of this issue in a long time either, so let us just close it now.</p> Development External issue ID 5806 External issue URL Rank 0|i01m47: