[DBWG] Nonconformant X.509 issuer+subject names in some Afrinic RPKI CA/EE certs

Tue Nov 18 05:09:29 UTC 2025

Dear AfriNIC (staff) team,

Would there be anything speaking against re-issuing those problematic 
objects ?

This will mean that all RPKI information published by AfriNIC will comply.

I believe the intentions of the issuers (resource holders) are clear and 
all parameters (validity duration etc) can be preserved.

Thanks,
Frank Habicht
[DBWG co-chair]

PS: Yes, there might be other mailing list applicable as well, but 
please include this list / WG in your answer ;-)

Hoping that this can be worked on and resolved swiftly, we're awaiting 
staff's input/updates.

On 11/17/2025 5:03 PM, Job Snijders wrote:
> Dear all,
> 
> Almost 3 years ago I reported a RPKI standards compliance issue with the
> way AfriNIC's RPKI system encoded certain text strings. Through
> extensive investigation we learned that the root cause was a
> configuration error caused by a documentation bug in OpenSSL.
> 
> Since then, the OpenSSL project corrected its documentation, release new
> versions of their software, and AfriNIC started using an updated
> configuration through which the issue was mitigated - for new object
> issuances going forward. All positive steps towards resolution.
> 
> Since 2023, rpki-client project have repeatedly requested AfriNIC to
> re-issue all remaining problematic objects in order to be able to remove
> an exception in rpki-client's codebase. A substantial number of objects
> have been re-issued, but not all. The rpki-client project considers it
> highly undesirable to continue carrying special case code to carve out
> an exception for AfriNIC's past configuration issue. We'd very much like
> to resolve this matter fully and close the case.
> 
> As of today, there still are 988 objects which contain a nonconformant
> X.509 issuer name and 657 objects which contain a nonconformant X.509
> subject name. See https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net.html
> for an up to date overview.
> 
> There list of affected prefixes is attached to this email in the file
> "afrinic-nov-2025-nonconformant-vrps.txt"
> 
> Should the RPKI-client project moves forward with removing the special
> case exception, the number of Validated ROA Payloads under the AfriNIC
> trust anchor would temporarily reduce from 21,027 to 19,480 Unique VRPs
> (until the associated ROAs are reissued).
> 
> The effect on the global Internet routing system would be that about
> 6,000 BGP route announcements convert from "valid" to "not-found" and
> would no longer enjoy the benefits of RPKI Route Origin Validation
> protection.
> 
> The rpki-client project currently is considering removing the carved out
> exception and accept the unfortunate consequence that a number of BGP
> routes will be considered ROV "not-found", until such time that
> AfriNIC's system has re-issued the associated ROAs.
> 
> We'd like to solicit your input on this matter on how to proceed.
> 
> Kind regards,
> 
> Job
> rpki-client maintainer
> 
> On Thu, 16 Mar 2023 19:53:22 +0100, Job Snijders via DBWG wrote:
>> Dear all,
>>
>> While reading RFC 6487 section 4.5, I noticed that all CA certificates
>> representing Afrinic members under the Afrinic trust anchor appear
>> nonconformant with regard to the constraints imposed on the X.509 Subject
>> field.
>>
>> The issue at hand is that the Subject name contains a distinguished name
>> which contains an instance of the CommonName attribute, which MUST be
>> encoded using the ASN.1 type 'PrintableString'. However, in the case of
>> Afrinic's Hosted RPKI solution, all such instances are encoded as
>> UTF8String. No need for emoji's in this particular data field! :-)
>>
>> I think the solution would be to change the issurance code that produces
>> value of the Subject - to use PrintableString instead of UTF8String, and
>> then re-issue all CA certificates and Signed Objects.
>>
>> As far as I can see, the Afrinic RPKI platform is the only system in the
>> global ecosystem which produces nonconformant issuer & subject names in
>> this particular way; therefor a resolution to this issue would allow all
>> Relying Party implementations to impose more strigent conformity checks
>> after this has been resolved.
>>
>> Kind regards,
>>
>> Job
>>
>> References:
>> Specification: https://www.rfc-editor.org/rfc/rfc6487.html#section-4.5
>> Another observation point: http://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net.html
>>                 ("Nonconformant X.509 issuer name" and "Nonconformant X.509 subject name")
>>
>> ps, one example:
>>
>> $ openssl asn1parse -in rpki.afrinic.net/repository/afrinic/muu9NJ1kyzF42IIOBBzyKn9pnok.cer -inform der -i -strparse 135
>>      0:d=0  hl=2 l=  72 cons: SEQUENCE
>>      2:d=1  hl=2 l=  19 cons:  SET
>>      4:d=2  hl=2 l=  17 cons:   SEQUENCE
>>      6:d=3  hl=2 l=   3 prim:    OBJECT            :commonName
>>     11:d=3  hl=2 l=  10 prim:    UTF8STRING        :F366EFDFAF       <#### ERROR, should be PRINTABLESTRING
>>     23:d=1  hl=2 l=  49 cons:  SET
>>     25:d=2  hl=2 l=  47 cons:   SEQUENCE
>>     27:d=3  hl=2 l=   3 prim:    OBJECT            :serialNumber
>>     32:d=3  hl=2 l=  40 prim:    PRINTABLESTRING   :9AEBBD349D64CB3178D8820E041CF22A7F699E89
>>
>>
>> From: yogesh at afrinic.net (Yogesh Chadee)
>> Date: Fri, 17 Mar 2023 10:37:03 +0400
>> Subject: [DBWG] Nonconformant X.509 issuer+subject names in almost all Afrinic RPKI CA/EE certs?
>>>
>>> Good morning.
>>>
>>> Thank you very much for the detailed explanation, references, and the
>>> test case.
>>>
>>> We would like to advise that we are working to resolve this bug as soon
>>> as possible and we will advise this list once it is resolved.
>>>
>>> Best regards,
>>>
>>> Yogesh Chadee
>>>
>>> AFRINIC
>>>
>>> _______________________________________________
>>> DBWG mailing list
>>> DBWG at afrinic.net
>>> https://lists.afrinic.net/mailman/listinfo/dbwg