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

Tue Aug 4 21:01:49 UTC 2026

Dear James, AfriNIC staff, AfriNIC as a whole,

while for one ORG i am responsible for, I did "the right thing" and 
re-issued ROAs as directed in previous emails, I'm also fortunate enough 
to recently have become responsible for another ORG and had not fixed 
everything myself. [on purpose?]

July 20th I received an email that I/we/the_ORG had not corrected the 
ROAs yet. Thanks for the email, so I did nothing. :-)
I have now seen that there are a number of new ROAs dated 2026-07-30
"Not valid after": 2036-07-30

Was that the same "not valid after" in the previously existing 
(improper) ROAs?

Thanks for re-creating the ROAs. [and removing the old ones, i think]

But: after below email from January, should we have received an update 
between July 31st and now?

Btw: i want to congratulate on this project being completed, in time. 
But hope for confirmation first that this is the case...

Thank you,
Frank
DBWG co-chair

On 1/29/2026 4:40 PM, James Chirwa wrote:
> Dear All,
> 
> As indicated in the previous communication, an action plan has been 
> established to address and eliminate the identified non-conformant 
> certificates.
> 
> The plan is designed to ensure that no unnecessary alarms are raised and 
> that potential conflicts are avoided. It will be implemented in phases, 
> with clearly defined activities and timelines, as outlined below.
> 
> *Phase 1: Awareness & Self-Remediation (DIY) (2 months)*
> 
>   * Activity: Direct communication to affected members, including a
>     clear problem statement and a step-by-step “How-To” guide.
> 
>   * Support: Weekly helpdesk calls will be available to assist members.
> 
>   * Goal: Enable the majority of active members to independently correct
>     their own ROAs
> 
> *Phase 2: Assisted Correction (2 Months)*
> 
>   * Activity: Targeted follow-ups with members who have not responded or
>     taken action.
> 
>   * Mechanism: i. Members can authorise AFRINIC to perform the "Create
>     New / Revoke Old" action for them.
> 
>                              ii. Revoke non-conformant ROAs that do not 
> have matching routes in the Default Free Zone
> 
>   * Support: Continued helpdesk availability.
> 
> *Phase 3: Final Deadline & Clean-up (2 Months )*
> 
>   * Activity: Issuance of final notices to members who have not taken
>     any corrective action.
> 
>   * Action: Revocation of all remaining non-conformant ROAs, followed by
>     the creation of new, compliant ROAs where applicable.
> 
> 
> The overall activity is planned for a maximum duration of six (6) 
> months. However, we anticipate that execution may be completed sooner, 
> as phases may be fast-tracked wherever possible.
> 
> We plan to commence this activity shortly, with final completion no 
> later than 31 July.
> 
> Regards,
> 
> James
> 
> We will be kickstart this activity shortly will a closing date of 31st 
> July, latest.
> 
> Regards,
> 
> On 16/12/2025 20:52, Frank Habicht wrote:
>> Thank you James.
>> Frank
>>
>> On 12/16/2025 5:04 PM, James Chirwa wrote:
>>> Dear Frank,
>>>
>>> We take note of the points you have raised and consider them to be 
>>> valid.
>>>
>>> A summary of the feedback is provided below:
>>>
>>> The action plan will include communication to the affected members, 
>>> primarily to avoid causing force alarms, while also allowing those 
>>> who wish to undertake the required steps independently to do so. This 
>>> will, however, be timebound.
>>>
>>> To achieve the objective of revoking all non-comforming certificates, 
>>> the majority of the revocation and re-keying will eventually be 
>>> carried out by staff.
>>>
>>> We are currently working on the action plan and defining appropriate 
>>> timelines for execution, which we expect to share in January.
>>>
>>> Regards,
>>>
>>> James
>>>
>>> On 16/12/2025 09:59, Frank Habicht wrote:
>>>> Dear Yogesh, whole WG,
>>>>
>>>> <nohat>
>>>>
>>>> please see inline...
>>>>
>>>> On 12/15/2025 5:45 AM, Yogesh Chadee via DBWG wrote:
>>>>> Dear Mr Snijders,
>>>>>
>>>>> I hope this email finds you well.
>>>>>
>>>>> While we understand that a quick resolution is favourable for 
>>>>> everyone, we believe it would be wise to ensure Certificate holders 
>>>>> are aware of the issue first.
>>>>
>>>> agreed.
>>>>
>>>>> Re-issuing a Certificate of a person who is unaware of the 
>>>>> situation, without prior consent, could have undesired consequences.
>>>>
>>>> At this place I would like to ask to be more specific. What 
>>>> consequences?
>>>>
>>>> I believe resource holders can end up with a certificate that they 
>>>> didn't have before. that they didn't create *themselves*. but it 
>>>> should reflect the intention of the resource holder when they 
>>>> created the initial certificate. And it should have the same 
>>>> properties.
>>>>
>>>>
>>>>> If this method does not yield the desired results, 
>>>>
>>>> Here I would like to get clarification about what time-line we look 
>>>> at for finding out whether the desired results materialised.
>>>> I believe when we rely on resource holder action, we have to expect 
>>>> a "long tail" and a small percentage of ROAs will not be deleted and 
>>>> re- issued, because of various reasons.
>>>> How long should software developers keep work-arounds?
>>>> Why should they keep them even now?
>>>> Exposing the incorrect data might give much more incentive for 
>>>> resource holders to take action...
>>>>
>>>>> AFRINIC will then consider a quicker resolution, having completed 
>>>>> the necessary information campaign.
>>>>
>>>> If AfriNIC relies on an information campaign....
>>>> ... has it started or when will it start?
>>>>
>>>> I personally still think that there is less risk, faster resolution, 
>>>> more certainty if AfriNIC could re-issue the certificates in question.
>>>>
>>>> If useful, AfriNIC could probably get (informal) support from 
>>>> external sources when considering the best methodology.
>>>>
>>>> It will be good to inform resource holders as objects are changed.
>>>> But this will be (i believe) much less effort than the above 
>>>> mentioned "information campaign". Which will not be needed if 
>>>> AfriNIC decides to *correct* the RPKI data on its own initiative.
>>>>
>>>> I understand that we got to this situation *not* because of any 
>>>> fault of AfriNIC part, nor on resource holders. But AfriNIC has the 
>>>> opportunity to "go the extra mile" and support resource holders more 
>>>> than absolutely necessary.
>>>>
>>>> Others are doing unilateral changes to improve database consistency 
>>>> as well - e.g. "RIPE-NONAUTH" cleanup.
>>>>
>>>> It's a way of proactively doing something "for the good of the 
>>>> internet".
>>>> And to be honest, in my personal opinion, if this is not done, it 
>>>> will be harder for AfriNIC to credibly claim to do all that's needed 
>>>> to support RPKI adoption.
>>>>
>>>> All of this just my personal opinion without any hat.
>>>>
>>>> Regards,
>>>> Frank Habicht
>>>>
>>>>
>>>> _______________________________________________
>>>> DBWG mailing list
>>>> DBWG at afrinic.net
>>>> https://lists.afrinic.net/mailman/listinfo/dbwg
>>>
>>
> -- 
> James Chirwa
> Head of Member Services
> African Network Information Centre (AFRINIC) Limited
> t: +230 403 51 00 | dir: +230 403 51 42
> f: +230 466 6758
> w:www.afrinic.net | tt: @afrinic
> SM: facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia
> 