Wat betekent de “check-in”-status op het ACME-dashboard?

De check-instatus geeft aan of een ACME-client actief communiceert met de ACME-endpoint en de ARI (Automatic Renewal Information) ophaalt.

Deze status kan alleen correct worden bijgehouden wanneer de ACME-client:

  • ARI ondersteunt
  • actief het ACME-endpoint benadert
  • regelmatig renewal windows ophaalt

Waarom hebben sommige domeinen wel een check-instatus en andere niet?

Voorbeeld:

Wel actief gecontroleerd:

  • cert.domein.nl
  • www.domein .nl

Niet actief gecontroleerd:

  • domein.direct
  • domein-domein.nl

Bij deze laatste twee is zichtbaar dat de ARI-endpoints niet worden aangeroepen in de logs.

Hoe kan het dat ARI niet wordt gebruikt?

Mogelijke oorzaken zijn:

  • een andere ACME-client beheert deze certificaten
  • de client ondersteunt geen ARI
  • de client is niet correct gekoppeld aan het ACME-dashboard
  • certificaten zijn handmatig of via een andere workflow uitgegeven

Is het mogelijk dat meerdere ACME-clients dezelfde certificaten beheren?

Ja.
Wanneer meerdere clients of systemen worden gebruikt, kan het voorkomen dat:

  • niet alle certificaten zichtbaar zijn in dezelfde ARI-tracking
  • check-in status onvolledig is
  • renewal-informatie verspreid raakt over meerdere systemen

Waarom is het renewal-schema op wekelijks ingesteld in plaats van dagelijks?

Een wekelijkse check heeft als gevolg dat ARI-informatie minder frequent wordt opgehaald.

Het nadeel hiervan is:

  • vertraagde detectie van wijzigingen in renewal windows
  • minder snelle reactie op urgente wijzigingen

Wat is het voordeel van ARI met dagelijkse checks?

ARI maakt het mogelijk om automatisch:

  • renewal windows aan te passen
  • mass revocation events door te geven
  • binnen korte tijd (zelfs < 24 uur) nieuwe certificaatorders te triggeren

Dit werkt alleen optimaal wanneer de ACME-client dagelijks het renewal window ophaalt.

Wat gebeurt er als de cliënt niet dagelijks controleert?

Als de client slechts wekelijks controleert:

  • kunnen urgente wijzigingen niet tijdig worden opgepakt
  • werkt automatische aanpassing van renewal windows minder effectief
  • kan vertraging ontstaan in certificaatvernieuwingen of revocations

Kloppen de certificaat-fingerprints in de API?

De gecontroleerde vingerafdrukken zijn correct en komen overeen met de data in het systeem.

Zelfs na herberekening van de fingerprint zijn geen afwijkingen gevonden.

Waarom kan er toch een mismatch in fingerprints ontstaan?

Mogelijke oorzaken zijn:

  • het gebruik van een oud certificaat (na reissue)
  • lokale berekening van fingerprints op basis van verouderde data
  • vergelijking met een eerdere certificaatversie in plaats van de actuele versie

Wat is belangrijk om te controleren bij fingerprint-vergelijking?

Het is belangrijk om te verifiëren:

  • welke certificaatversie wordt gebruikt (actueel vs. reissued)
  • hoe de fingerprint lokaal wordt berekend
  • of de juiste bron (API vs. cached data) wordt gebruikt

Kan een certificaat tussentijds veranderen?

Ja.
Sommige certificaten zijn tussentijds gereissued, waardoor:

  • de private key verandert
  • de fingerprint verandert
  • eerdere vergelijkingen ongeldig kunnen zijn

Wat is het advies voor een correcte vergelijking?

Zorg ervoor dat:

  • altijd de meest recente certificaatversie wordt gebruikt
  • fingerprints direct uit de API worden vergeleken
  • oude certificaatgegevens niet worden hergebruikt in controles