On 24/05/15 01:37, Jeffrey Walton wrote: > I have an odd situation, and I don't know what the expect behavior is. > It was experienced when attempting to validate a path for > usercenter.checkpoint.com. > > If I use s_client and `-showcerts`, I get a chain that terminates in > an old Root called "Class 3 Public Primary Certification Authority". > Its old and deprecated, so I tried to root or anchor trust in the next > lower intermediate. > > The next lower intermediate is called ''VeriSign Class 3 Public > Primary Certification Authority - G5". Its sent in the chain, *but* I > downloaded it out of band from Symantec's site. > > Then I ran s_client again with the downloaded version of the > certifcate (see below). It results in "Verify return code: 20 (unable > to get local issuer certificate)". > > After some digging, it looks like ''VeriSign Class 3 Public Primary > Certification Authority - G5" are two different certificates with two > different serial numbers. One is sent in the chain and one is > available for download. What changed is the G5 certificate was > promoted to a self signed root due to the former CA deprecation. But > it reused the Disntiguished Name and public key, so Authority Key > Identifier and Subject Key Identifier stayed the same. > > What is the expected behavior here? Should it fail or should it succeed? > > Does the chain override the root or anchor? I think RFC 4518 treats > them as different certificates, so it just looks like the old G5 > certificate is suprious and unnecessary. (... but confusing due to the > DN/SKI reuse)). This was fixed in the git 1.0.2 HEAD a little while ago. If you try that version it should work, and will be in 1.0.2b. A backport of the fix also exists for 1.0.1 but it hasn't hit the repo yet. Matt
