Issue generating Cloudflare API credentials

[chuckschilling]

Hello,

I am attempting to create the DNS provider record for a Cloudshare domain (intended for use with wildcards) using API credentials but am not sure where the corresponding info is for the API token. Also, Cloudshare is applying its own certificate and I am not sure whether that can be causing me issues in processing my cert request in Domino 12 using the Cert Store. Any help/direction you can provide would be most helpful.

[Daniel-Nashed]

What kind of information are you missing? Did you see this information at the Cloudflare website about API tokens

You need an API token and find the information on the Cloudflare site. The documentation what is needed on the Domino certstore side comes with the DNS provider configuration you imported via DXL.

Which certificate are you referring to for conflicts you could run into?

Please be very specific what your issue to be able to help you.

Thanks

Daniel Nashed

[chuckschilling]

Daniel,

Thank you for responding. I apologize if some of my questions/issues seem to be rather elementary - I should start out by saying I am not a full time Domino or network admin and so much of my frustration stems from this lack of experience with this aspect of things.

I work for a small company that operates a subscription website for multiple customers using a single wildcarded dns (production site is *.qsihosting.com) hosted on a Domino V9 server. We are in the process of upgrading to V12 on a different server. I am trying to generate a new SSL certificate request using a new Cloudflare domain (qsi-web.com using the CertStore to leverage the built-in LetsEncrypt integration and each cert request submission just drops into Pending Status and doesn't appear to be going anywhere. I have set up the DNS Configuration document for Cloudflare provided here, and created a DNS Provider document with the credentials the DNS config doc says I need, but then when I submit the cert request, nothing happens. I have attached some screenshots.
Cert Store SSL Cert request.pdf Cloudflare DNS Provider doc.pdf

[chuckschilling]

Cert Store SSL Cert request.pdf Cloudflare DNS Provider doc.pdf

[Daniel-Nashed]

You are almost there. You are on a good way.

• The DNS-01 API is triggered by domain
• You should only specify qsi-web.com. Not the wildcard
• The document needs to have an account name
• For Cloudflare you need only an Authorization token. You could add the zone if you have it. Else it will be looked up -- as documented in the provider interface
• If you specify a zone, the zone must be OK. If you don't have it, just leave it out. The integration can look it up.
• Zone DNS is not the DNS zone. It is just a type of the setting

Once the settings are in place and you request a TLS credentials, CertMgr will trigger that a DNS challenge is used and uses the DNS provider integration. This also works for wildcard certs which match the domain you specify in the account document.

When DNS-01 challenges are used and an error occurs, there is a trace document with details. By default no log document is created when the operation is successful. This can be changed to keep logging for all requests.

I hope this helps. Else please provide more details what you see and what is happening. From what you provided this is the best information I can give you.

[chuckschilling]

Thank you Daniel. I think I'm definitely getting closer. Turning on cert mgr probably helped just a bit... But your instructions definitely are what is getting me closer, I'm pretty sure. I'm generating an error. I've attached the relevant info from the trace doc.

[Daniel-Nashed]

Yes you are getting closed.

• The request was triggered
• The request got sent to Cloudflare
• The result you see is directly coming from the Cloudflare API

It would be easier to search if you copy the log as text the next time. not as image, please! The error message is not clear to find on the Cloudflare side.

Did you remove the zone from the config? Can you verify your token is correct?

A token should look like this:

aaIZzQSnYNVfWxxtLrLjf2KeeFSOczzehRQyjxxT (my current token modified to show you what format it should have).

The error log shows you exactly what is sent to CF and what is returned. With every detail. But it also contains your token. So you should not post the actual token here.

The log and what is sent would be helpful if you can't figure it out on your own.

I can confirm the API works. I just tested it to get a new certificate for one of my domains to validate. This is more a CF config issue than a CertMgr issue. Please verify your settings again.

If that does not lead to a success you might need to share your detailed logs and settings offline. You can change the API token afterwards.

[chuckschilling]

Here's my last trace report:

Configuration: cfg_AuthKey = cfg_AuthToken = API TOKEN HERE cfg_CustomValue = cfg_DnsProviderDelay = 20 cfg_DnsZone = cfg_InternetAddress = cfg_Password = cfg_URL = https://api.cloudflare.com/client/v4/zones cfg_UserName =

Parameters: param_DnsTxtName = _acme-challenge.qsi-web.com param_DnsTxtValue = kd7f-nf4qqyoR1h7heVAD_ESDoL-Li-uQtZktEWIL8A param_Hostname = qsi-web.com param_RegisteredDomain = qsi-web.com

URL: url_Add = https://api.cloudflare.com/client/v4/zones//dns_records/ url_Lookup = https://api.cloudflare.com/client/v4/zones?name=qsi-web.com

Headers: headers_Add = Authorization: Bearer API TOKEN HERE headers_Add = Content-Type: application/json headers_Lookup = Authorization: Bearer API TOKEN HERE headers_Lookup = Authorization: Bearer API TOKEN HERE headers_Lookup = Content-Type: application/json headers_Lookup = Content-Type: application/json

Post: post_Add = {"type":"TXT","name":"_acme-challenge.qsi-web.com","content":"kd7f-nf4qqyoR1h7heVAD_ESDoL-Li-uQtZktEWIL8A","ttl":120} post_Lookup =

Results: ret_AddResult = {"result":null,"success":false,"errors":[{"code":7003,"message":"Could not route to /client/v4/zones/dns_records/, perhaps your object identifier is invalid?"}],"messages":[]}

ret_AddStatus = 404

ret_LookupResult = {"result":[],"result_info":{"page":1,"per_page":20,"total_pages":0,"count":0,"total_count":0},"success":true,"errors":[],"messages":[]}

ret_LookupStatus = 200

JSON results: retJSON_Add.errors.0.code = 7003 retJSON_Add.errors.0.message = Could not route to /client/v4/zones/dns_records/, perhaps your object identifier is invalid? retJSON_Add.result = null retJSON_Add.success = false retJSON_Lookup.result_info.count = 0 retJSON_Lookup.result_info.page = 1 retJSON_Lookup.result_info.per_page = 20 retJSON_Lookup.result_info.total_count = 0 retJSON_Lookup.result_info.total_pages = 0 retJSON_Lookup.success = true

[chuckschilling]

Daniel, good news - I was able to use Let's Encrypt to generate the cert submission successfully. I reworked my CNAME record and that seems to have done the trick.

[Daniel-Nashed]

Glad it worked. Even I don't know why the CNAME made a difference. DNS-01 challenges don't require DNS records unless you configure CNAME validation, which I don't think you are using.

Your host name would also work with a HTTP-01 challenge. But that would only happen if the DNS-01 integration is triggered. Does it also work for wildcard certs?

It's really difficult to help if you don't provide the full information.

[Daniel-Nashed]

You asked another question to support about why the certificate expiration is different. The certificate you currently run is a Google certificate, probably not provided by Domino.

Here is what I get from your server. This isn't a Let's Encrypt certificate.

This certificate is a wild card cert. What you have shared from CertStore is a certificate for a single host.

Certificates are a difficult topic. Without more details it is really challenging to help.

Please provide more details and don't filter what you think is not helpful.

I don't understand what you did with the CNAME. You also only shared the failed request. Not the successful one.

Subject    : /CN=qsi-web.com
SAN (DNS)  : qsi-web.com, *.qsi-web.com
Issuer     : /C=US/O=Google Trust Services LLC/CN=GTS CA 1P5
Not Before : 2024.06.03 14:15:48
Not After  : 2024.09.01 14:15:47 (expires in 86.0 days)

Serial     : 77FFAA49C09126A30EAB57A0349D3950
Sign Alg   : sha256WithRSAEncryption
KeyUsage   : DigitalSignature
Extensions : BasicConstraints, KeyUsage, ExtKeyUsage
ExtKeyUsage: TLS Web Server Authentication
Key        : RSA 2048 bit

OCSP       : http://ocsp.pki.goog/s/gts1p5/ZHtKJt1X6yI
AuthInfoURL: http://pki.goog/repo/certs/gts1p5.der
CRL        : http://crls.pki.goog/gts1p5/73YPb5j-D5g.crl

AuthKeyId  : D5:FC:9E:0D:DF:1E:CA:DD:08:97:97:6E:2B:C5:5F:C5:2B:F5:EC:B8
SubjKeyId  : 19:19:28:65:29:15:3F:A3:21:FB:FF:6C:B1:3A:2D:DB:D4:8B:5F:BF
MD5        : 5A:0D:59:41:99:75:D2:19:A8:0E:53:C5:C1:8B:57:86
SHA1       : FE:FE:DD:F5:36:0C:17:1B:0B:8F:C0:CA:02:12:30:82:B2:0E:BF:13
SHA256     : 81:8A:72:7B:AD:0F:CE:0C:3B:82:27:3E:49:27:BD:19:B3:84:15:21:BA:B2:2B:C8:D3:B8:9C:E4:5A:AA:0A:8F

[chuckschilling]

Daniel, I really appreciate your assistance and apologize for not giving you all the information you might find helpful. This is not intentional - I'm just not always sure what that might be. I've learned a little more about what Cloudflare is doing. They are applying their own SSL to inbound traffic - if the SSL mode is set to "flexible", it transmits in HTTP to the origin server. If the SSL mode is set to "full", it requires that the DNS challenge succeed. I've enclosed screenshots of these as well as a PDF of the latest wildcard cert request I processed for *.qsi-web.doc (it was successful, so there is no corresponding trace log to send.

Would you be willing to do a zoom call or team viewer session to review this?
Current issued certificate request.pdf

[Daniel-Nashed]

With the information you provided, it looks like the wildcard certificate operation worked and you have a valid wildcard certificate. From Domino side this looks all OK.

You are using Cloudflare (CF) to protect your server. That means all requests go thru CF and the certificate you see in your browser is a certificate CF manages for you.

Depending on the mode on the CF side, you need a back-end certificate from CF. It's a certificate with a long certificate expiration (my one is valid for 15 years), which you import to certstore.nsf to have Domino use the back-end certificate from CF. But then you can only access the server via CF, because Domino would use this certificate always for requests for this server name.

You can import the key and certificate you get from CF into cerstore.nsf with the import functionality in the certstore.nsf UI.

The different modes on CF side are well documented. You really need to decide what you want to do. This isn't a Domino question. It's more a CF question.

On the CF side you can configure which DNS name is CF protected.

I hope this helps and explains it?

[chuckschilling]

Thank you for the follow up, Daniel. I'll let you know how it goes.

[chuckschilling]

Daniel, I got a little sidetracked. I'm looking at this now and I'm not sure whether I should be importing this into the existing request, replacing the initial request, or adding a new request. I've looked at each of these options and none seem to be an exact fit. The Origin CA certificate generates an Origin Certificate key and a separate private key. I looked at the existing request in our Cert Store, and there is an action button to Import TLS credentials; however, the resulting prompt asks only for a file name and a password. I looked on the form at the Security/Keys and Manual tabs and didn't see anything that looked like a good match either. Can you tell me where the Origin CA certifier info I just generated at Cloudflare needs to be placed in the Cert Store?

[Daniel-Nashed]

• Copy all the PEM data into a single file
• Create a new TLS Credentials document
• Use the import action to import the PEM file
• Private key in the PEM file has no password so you don't need to enter a password

This should create a new TLS Credentials document for this CF certificate. It will not work to have two different TLS Credentials for the same host name. You have a wild card certificate already from CF. That will be used for all servers, which have no explicit certificate for a host name So a direct match beats a wildcard cert. So in case you want some direct connections and not everything thru CF, you can still use explicit hosts (SANs). But you cannot have two different wild card certificates.

I hope this explains it and the next questions you would ask about it once the import is done.