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

Thu Feb 19 14:20:19 UTC 2026

Dear AfriNIC,

Thank you for sharing the timeline. Please note this announcement:

*** STARTING TUESDAY AUGUST 18th, 2026 THE RPKI-CLIENT IMPLEMENTATION
WILL REJECT NON-CONFORMANT CERTIFICATES. ***

The above means that if AfriNIC somehow misses its self-imposed July
31st 2026 deadline, it'll cause RPKI service affecting issues for
affected AfriNIC members. 

I believe I've gone above and beyond what can reasonably be expected
from an unpaid volunteer:

* I notified AfriNIC in a timely fashion (already back in March 2023)
  https://lists.afrinic.net/pipermail/dbwg/2023-March/000436.html

* I helped AfriNIC by pinpointing & fixing the root cause, a
  documentation bug in OpenSSL:
  https://github.com/openssl/openssl/pull/23699

* I improved AfriNIC's monitoring at the following URL to help increase
  AfriNIC's staff visibility into this issue:
  https://validator.afrinic.net/rpki/rcynic/rpki.afrinic.net.html

* I've repeatedly, more than ten times over the last 3 years, reminded
  and pleaded AfriNIC to please re-issue the few remaining
  non-conformant certificates.

DON'T MISS THE DEADLINE: NON-CONFORMANT CERTIFICATES WILL STOP WORKING.

Kind regards,

Job

ps. I note it is quite remarkable to observe AfriNIC not shouldering the
    responsibility for this certificate reissuance work itself. To me it
    really doesn't make a lot of sense to request tens of members to
    perform tedious error-prone tasks while at the same time AfriNIC
    could just as easily automatically solve it for all its members in
    one go. AfriNIC's CA implementation caused an issue and AfriNIC's
    system should fix the issues it caused. The strangeness of these
    proceeding has been noted by myself and others on this mailing
    list...

On Thu, Jan 29, 2026 at 05:40:28PM +0400, James Chirwa via DBWG 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

> _______________________________________________
> DBWG mailing list
> DBWG at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/dbwg