Solved! - Re: Setting Issuer Alternative Name

Robert Moskowitz rgm at htt-consult.com
Sun May 14 23:52:33 UTC 2023


i asked a question about the whole aKID and sKID piece on the pkix list 
and Peter Gutmann said something that I had lost track of in the weeds...

The content of keyid used in:

authorityKeyIdentifier = keyid

Is the sKID from the signing cert.  argh.

So going back to the hack that Viktor had given me to have control over 
the Validity dates in my self-signed cert,,,,

I realized that was where the aKID was really coming from, and that cert 
was generated before I worked out controlling sKID in the conf:

subjectKeyIdentifier = $ENV::DET

So go all the way back to start.

and Now I have my certs with the sKID and aKID I was trying to get.

Well there is 2+ days of struggle and distracting all of you from other 
tasks!

Thank you Viktor for you time.

I can't directly control what is in aKID, as it is pulling aKID from the 
signing cert.  Fix that and..

Bob

On 5/14/23 15:28, Robert Moskowitz wrote:
>
>
> On 5/14/23 14:00, Viktor Dukhovni wrote:
>> On Sun, May 14, 2023 at 12:44:48PM -0400, Robert Moskowitz wrote:
>>
>>> I looked at that manpage and tried:
>>>
>>> authorityKeyIdentifier =
>>> otherName:1.3.27.16.2.1.1;BITSTR:20010030000000052aeb9adc1ce8b1ec
>> https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1
>>
>>         AuthorityKeyIdentifier ::= SEQUENCE {
>>            keyIdentifier             [0] KeyIdentifier OPTIONAL,
>>            authorityCertIssuer       [1] GeneralNames OPTIONAL,
>>            authorityCertSerialNumber [2] CertificateSerialNumber 
>> OPTIONAL  }
>>
>> You're trying to set the AKID to just the GeneralName, but it has to be
>> a tagged sequence,
>
> I did spend some time digging to get what a "tagged sequence" is let 
> alone represent  it but can't find it in 5280
>
>>   and note that "authorityCertIssuer" is the name of
>> the "grandparent" of the certificate in which the AKID appears, along
>> with the authorityCertIssuer you'd need to provide the serial number
>> of the parent certificate.
>
> The two together seems only mandated in sec A.2.
>
> I am not finding any discussion on authorityCertIssuer being that of 
> the "grandparent", can you point me to that?
>
>> But as I mentioned before, I don't expect that support for names other
>> than directory names in the AKID extension is particularly common.
>
> Well I could put:
>
> e.d.c.a.b.0.b.e.0.6.8.2.e.0.b.9.5.0.8.f.f.3.e.f.f.3.0.0.1.0.0.2.ip6.arpa.
>
> ? It will exist (we are for now doing this under driptesting.org as it 
> will be a bit of process to get 3.0.0.1.0.0.2.ip6.arpa. delegated).
>
> But that is 73 bytes to show a 16 byte value.
>
>> You're better off with just "keyIdentifier", liking the child cert
>> to the key if of the parent cert.
>
> I assume you mean:
>
> authorityKeyIdentifier = keyid
>
> and I can't see how to set keyid to 20010030000000052aeb9adc1ce8b1ec
>
> I can control subjectKeyIdentifier like:
>
> subjectKeyIdentifier = 20010030000000052aeb9adc1ce8b1ec
>
>             X509v3 Subject Key Identifier:
>                 20:01:00:30:00:00:00:05:2A:EB:9A:DC:1C:E8:B1:EC
>
> Which is defined as:
>
> SubjectKeyIdentifier ::= KeyIdentifier
>
>
> I tried
>
> authorityKeyIdentifier = keyid=20010030000000052aeb9adc1ce8b1ec
>
> And get an error
>
> authorityKeyIdentifier = keyid:20010030000000052aeb9adc1ce8b1ec
>
> Just uses the keyid as is:
>
>             X509v3 Authority Key Identifier:
> 0F:4E:5E:54:C2:4F:80:9E:E5:79:CD:B4:14:9B:BF:EB:A8:57:CB:CA
>
>
>
>>
>> Perhaps I should not have mentioned issuer SANs, you probably have no
>> use for them.  Do use the appropriate data type in the EE SAN.
>>
>



More information about the openssl-users mailing list