[openssl-users] Expected behavior for verification when a subordinate in a chain is promoted to a self signed root?

[Matt Caswell]

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