Tick-Fixtures (DUMMY-Daten)

Alles hier ist erfunden und zum Austauschen gedacht. Domains sind *.example.org/*.example.net (reserviert, RFC 2606).
Es gibt hier keinen privaten SchlĂŒssel. Die SchlĂŒssel zu den Demo-CSRs wurden beim Erzeugen verworfen.

Datei Zweck
registrar/<registrar_ref>.json Antwort des Registrars auf sslInfo fĂŒr diese Referenz, in derselben Form wie live (returnCode, status, zertifikat, validationDNS, comodostatus). Fehlt die Datei, „kennt der Registrar die Referenz nicht“.
dns.json {"<challenge_name>": "<cname-ziel>"} statt echter DNS-Auflösung
demo-*.csr, demo-issued.crt CSRs fĂŒr die Demo und das dazu passende (selbstsignierte) Zertifikat

Demo durchspielen

export TLSGATE_GUARD=off                       # lokal/Dev; produktiv sudo bzw. Dienst-User
export TLSGATE_MOCK=1                          # --fixtures nur mit ausdruecklichem Mock-Schalter
php bin/order_cli.php order new bwa --csr resources/fixtures/tick/demo-pending.csr    # -> #1
php bin/order_cli.php order new bwa --csr resources/fixtures/tick/demo-issued.csr     # -> #2
php bin/order_cli.php order new bwa --csr resources/fixtures/tick/demo-rejected.csr   # -> #3
php bin/order_cli.php order ref 1 DEMO-PENDING                 # im Portal bestellt, Referenz eintragen
php bin/order_cli.php order ref 2 DEMO-ISSUED
php bin/order_cli.php order ref 3 DEMO-REJECTED
php bin/order_tick.php --fixtures resources/fixtures/tick --dry-run   # zeigen, nichts schreiben
php bin/order_tick.php --fixtures resources/fixtures/tick             # mehrmals: je Lauf ein Schritt je Bestellung
php bin/order_cli.php order show 2

Erwartet: #1 geht nach awaiting_dns, der nĂ€chste Lauf sieht den CNAME aus dns.json → validated (Herkunft
fixture, nicht dns_observed), danach wartet es auf ein Zertifikat. #2 lÀuft in drei LÀufen bis issued.

3 geht sofort nach failed. Alle Ereignisse aus der Demo tragen die Herkunft fixture. So sieht eine Demo

in der DB und spÀter im Monitor nie wie ein echter Ablauf aus.

Gegen echte Daten tauschen

  1. php bin/user_cli.php cred test <gruppe> muss grĂŒn sein.
  2. Eine echte Antwort aufzeichnen, unverÀndert in der Form, die der Tick liest:
    sudo TLSGATE_GROUP=<gruppe> php bin/soap_cli.php record <orderNumber> > resources/fixtures/tick/registrar/<orderNumber>.json.
    Vorher prĂŒfen: Die Antwort enthĂ€lt echte Bestelldaten, also keine Kunden- oder Kontaktdaten ins Repo. Tests mit echten
    Aufzeichnungen besser in einem eigenen Verzeichnis außerhalb des Repos halten (--fixtures <verzeichnis>).
  3. Offen, nicht belegt: die echte Form von validationDNS. Gelesen werden heute ein String "<name> CNAME <ziel>" und ein
    Objekt {"name":
, "value":
}. Welche Werte status live annimmt, ist in der SOAP-Doku nicht enumeriert. Deshalb gilt
    nur comodostatus.certificateStatus = Rejected/Revoked (bzw. ssl_revoke) als Fehler, alles Unbekannte bleibt „pending“.
    Die Abbildung steht an einer Stelle: RegistrarStatus::fromSslInfo().