Indeed, just wanted to report that reversing the chain order fixed the issue :-)
Jason, Thanks for the script :-) On Tue, May 23, 2017 at 7:28 PM, Jason Tucker <[email protected]> wrote: > I've got a quick-n-dirty bash/keytool script script here that I like to use > to verify the cert chain order: > > https://gist.github.com/guzzijason/026998189b0a57ef0ba2a05d1baf966a > > __Jason > > On Tue, May 23, 2017 at 4:22 PM, Jeff Elsloo <[email protected]> wrote: > > > It should be noted that you might need to use an external tool of some > > sort to order and verify the certificate chain properly. I believe > > that's what we did when we ran into the problem. > > -- > > Thanks, > > Jeff > > > > > > On Tue, May 23, 2017 at 10:05 AM, Jason Tucker <[email protected]> > > wrote: > > > +1 to what Dave said. A full cert chain shouldn't be a problem in > Traffic > > > Ops. Best to make sure server cert is at the top of the chain, and the > > rest > > > of the certs are below, in order, with the CA cert last. > > > > > > __Jason > > > > > > On Tue, May 23, 2017 at 2:15 PM, Dave Neuman <[email protected]> > wrote: > > > > > >> Hey Oren, > > >> Yes you can enter an externally created, full-chain certificate in > > Traffic > > >> Ops; we do this all the time. You shouldn't need to do anything > special > > >> besides make sure that the certificate chain is in the correct > order. I > > >> think you need to have the server (wildcard first) then the > > intermediates, > > >> then the root block. If that doesn't work, I would try reversing the > > >> order. > > >> > > >> --Dave > > >> > > >> On Tue, May 23, 2017 at 4:45 AM, Oren Shemesh <[email protected]> > wrote: > > >> > > >> > Hi, > > >> > > > >> > After creating a DS which supports SSL, and using an official > > certificate > > >> > created by GoDaddy (As opposed to a self-signed certificate > generated > > by > > >> > Ops), we ran into the following issue: > > >> > > > >> > An SSL scan from https://www.ssllabs.com/ssltest , done on > > >> > tr.<ds-name>.<cdn-domain>, complained about the fact that the > server's > > >> > certificate chain is incomplete. > > >> > (Do try this tool on your servers, you might find the results > > >> interesting) > > >> > > > >> > I tried pasting the full certificate chain (Made from four blocks, > > each > > >> > marked with "-----BEGIN CERTIFICATE-----" and "-----END > > CERTIFICATE-----" > > >> > lines) into Ops, but this made the traffic router's situation worse: > > It > > >> > consumed the certificate chain with no problem, but now it presents > a > > >> > certificate for GoDaddy, instead of a certificate for * > > >> > .<ds-name>.<cdn-domain>. > > >> > So, I guess that when pasting a certificate for a DS via Ops, it > only > > >> uses > > >> > the first block in the chain. > > >> > > > >> > A quick check with tomcat documentation shows that in order for it > to > > >> > present a full-chain certificate, two different 'keytool -import' > > >> commands > > >> > should be used, one for the 'root' and another for the 'server' > (See > > >> > https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html# > > >> > Importing_the_Certificate > > >> > ). > > >> > This might explain the problem: Given the current Ops GUI, I am > > entering > > >> a > > >> > chain of certificates in one block of text, using it as if it is a > > >> 'server' > > >> > certificate, instead of breaking it into a 'root' and a 'server' > > >> > certificate. > > >> > > > >> > So after all this, here is my question: > > >> > > > >> > Is there a way to use an externally-created, full-chain certificate, > > in > > >> > Traffic Ops ? > > >> > > > >> > Thanks a lot, Oren. > > >> > > > >> > -- > > >> > > > >> > *Oren Shemesh* > > >> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | > > [email protected] > > >> > <[email protected]> > > >> > > > >> > > > -- *Oren Shemesh* Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | [email protected] <[email protected]>
