I'm running it in docker

Unhandled exception. OpenQA.Selenium.WebDriverTimeoutException: Timed out after 40 seconds
 ---> OpenQA.Selenium.NoSuchElementException: no such element: Unable to locate element: {"method":"xpath","selector":"//div[@data-testid = 'zone-cards']"}
  (Session info: headless chrome=97.0.4692.99)
   at OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response errorResponse)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
   at OpenQA.Selenium.Remote.RemoteWebDriver.FindElement(String mechanism, String value)
   at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
   --- End of inner exception stack trace ---
   at OpenQA.Selenium.Support.UI.DefaultWait`1.ThrowTimeoutException(String exceptionMessage, Exception lastException)
   at OpenQA.Selenium.Support.UI.DefaultWait`1.Until[TResult](Func`2 condition)
   at DotNetCertBot.CloudFlareUserApi.CloudFlareServiceSelenium.<>c__DisplayClass11_0.<<GoToZoneDns>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at DotNetCertBot.CloudFlareUserApi.CloudFlareServiceSelenium.GoToZoneDns(String zone)
   at DotNetCertBot.CloudFlareUserApi.CloudFlareServiceSelenium.AddChallenge(DnsChallenge challenge, String zoneName)
   at DotNetCertBot.Host.CertificateService.Issue()
   at DotNetCertBot.Host.Program.<Main>(String[] args)

An alternative implementation of IDnsProviderService to the cloudflare dns api based on the official library, for better and easier work with non-free domains from Freenom on cloudflare (i.e. to all other domains).

Selenium-based cloudflow client implementation is only needed to manage recording for free Freenom domains. This was the only way to get around the prohibition of installing cloudflare to automate the management of such domains. But it is not correct to use this provider for other domains. the speed and stability of this implementation is not 100% and is unnecessary.

Is it possible to generate a acme certificate (acme.json) rather than .pem and .key file?

Just wondering if this program is still working. I tried to run it many times both in docker and on windows however both resulted in the program ending on the line last url cloudflare login page or something to that effect.

To simplify the integration of the client for issuing certificates (as well as for automating the issuance of certificates), it would be convenient to choose where and in what way the certificate will be sent.
For example, upon completion of the client's work, he could send ready-made certificates to the gitlab repository, where ci-cd rolled out this certificate across servers, or he himself would put these certificates on sftp to the right place on the server.

Road map:

1. Abstraction of certificate output
2. Implementation for saving to local file system (default)
3. Implementation for saving to the repository in gitlab
4. Implementation for saving via sftp