Voor alle PKI-O certificaten die we aan de Kadaster kant (en breed binnen de overheid gebruiken) geldt dat deze vervangen moesten worden voor 1 oktober ivm het intrekken van het root certificaat. Voor meer informatie zie de site van Logius: Intrekking PKIoverheid certificaten afgerond | Logius.
Voor het domein waar de BAG API is het certificaat op tijd vervangen, dat je foutmeldingen krijgt komt hoogstwaarschijnlijk omdat ergens in jullie eigen infrastructuur het nieuwe root certificat voor PKI-O niet vertrouwd wordt.
Wat we wel vreemd vinden is dat je de foutmeldign maar incidenteel krijgt, wij weten iig wel zeker dat we altijd hetzelfde (nieuwe) certificaat gebruiken.
Krijg het zowel in mijn ontwikkelomgeving (gekoppeld aan Ziggo) als produktieomgeving (Digital Ocean cluster in AMS).
Het vreemde is dat een search met enkel alleen BRK requests van begin tot eind bij herhaling gewoon goed gaat. Zelf heb ik een generiek certificaat voor al mijn subdomeinen. Dat lijkt bij jullie anders aangezien het BRK certficaat gewoon goed werkt.
Je zou verwachten dat certificaat afhandeling niet verstoord mag worden door tussenliggende proxies.
Ben overigens geen expert in certificaat afhandeling en om die reden nog niet diep in gedoken. Vandaar eerst mijn vraag aan jullie.
Wij kunnen hier (voor zover ik nu kan nagaan) niets aan doen. Wij hebben een geldig certificaat voor de domeinen geinstalleerd, waarbij er nu dus een andere root certificaat wordt gebruikt. Als je op jouw omgevingen het root-certificaat niet kent of niet vertrouwd dan krijg je foutmeldingen. In je browser regelen de makers van je browser dit, vanuit een applicatieomgeving moet je zelf zorgen dat je het nieuw PKI root certificaat vertrouwd.
Ben even searches aan het testen met (1) alleen BRK, (2) BRK en BAG, en (3) BRK, BAG en Ruimtelijke Plannen. Omdat er met de parallellisatie meldingen door elkaar in de log file komen is het misschien niet BAG maar Ruimtelijke Plannen.
CONNECTED(00000005)
depth=0 serialNumber = 00000001821699180000, C = NL, ST = Zuid-Holland, L = 's-Gravenhage, O = Rijkswaterstaat, OU = Rijksoverheid, CN = ruimte.omgevingswet.overheid.nl
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 serialNumber = 00000001821699180000, C = NL, ST = Zuid-Holland, L = 's-Gravenhage, O = Rijkswaterstaat, OU = Rijksoverheid, CN = ruimte.omgevingswet.overheid.nl
verify error:num=27:certificate not trusted
verify return:1
depth=0 serialNumber = 00000001821699180000, C = NL, ST = Zuid-Holland, L = 's-Gravenhage, O = Rijkswaterstaat, OU = Rijksoverheid, CN = ruimte.omgevingswet.overheid.nl
verify error:num=21:unable to verify the first certificate
verify return:1
Ja, dit wordt gefixt met een nieuw certificaat. Het is alleen nog niet duidelijk wanneer dat nieuwe certificaat er is, daar wordt aan gewerkt maar is door de manier waarop het in elkaar steekt een wat complexe route die daardoor wat tijd kost.
We hadden verwacht dat het opgelost zou zijn, maar het nieuwe certificaat bleek niet te matchen met de info op de server. Het duurt dus helaas nog wat langer.