Digicert certonly 403

I'm trying to use certbot with Digicert. I have about 100 of them expiring over the next year. I plan on submitting new csr each time. This will be on a central server as I don't have access to all of them and people send me csrs. Some domains are not accessible via outside dns.

I got all Acme directories setup on the Digicert side.

My first test domain is:
blog.konicaminolta.us (domain is not running on the server where I run certbot).

I ran this command:
certbot certonly --csr blog.konicaminolta.us.csr --webroot --webroot-path D:\IBM\HTTPServer9\htdocs.well-known\acme-challenge --register-unsafely-without-email --eab-kid "kid" --eab-hmac-key "hmackey" --server "https://acme.digicert.com/v2/acme/directory/"

It produced this output:
erver "https://acme.digicert.com/v2/acme/directory/"
Saving debug log to C:\Certbot\log\letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
e[31mAn unexpected error occurred:e[0m
e[31macme.messages.Error: unauthorized :: CSR includes different number of names than specifies in the order: e[0m
Please see the logfiles in C:\Certbot\log for more details.

My web server is (include version):

IBM Http Server 9.0.5.4.

The operating system my web server runs on is (include version):
Windows

I can login to a root shell on my machine (yes or no, or I don't know):
Yes. Windows

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
1.7.0

I verified the csr on digicert csr checker and it looks ok.

From log, it appears to validate dns then

2020-09-29 08:12:05,092:DEBUG:acme.client:JWS payload:
b'{\n "csr": "MIIC9jCCAd4CAQAwgbAxHjAcBgNVBAMMFWJsb2cua29uaWNhbWlub2x0YS51czELMAkGA1UEBhMCVVMxEzARBgNVBAgMCk5ldyBKZXJzZXkxDzANBgNVBAcMBlJhbXNleTE3MDUGA1UECgwuS29uaWNhIE1pbm9sdGEgQnVzaW5lc3MgU29sdXRpb25zIFUuUy5BLiwgSW5jLjEiMCAGA1UECwwZVGVjaG5pY2FsIE1pZGRsZXdhcmUgU3ZjczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJmKlMRizhadoGDjdLJj5Hyn6fsGqw7PmL5pExiD36c525BMGB-bYsM_U6cojMPOrmYOZ4aTXvLql6OdmCavFx-yJJim3ZGvyI7HdRor5nEoa6vlex8TfkukEPIHagMvNNDunG4e-cUbNvdLPoEgIw8FxUk3qZw3MY0DCXHfmmXAdnNjUNkFKlEnEdpp4RP4VQkTfrmdg1txtVNK3bU9DlTdBpM1VY8htTq53vDXjz2ruBjE3rikWRdorCRM6YekPw7ml4I4XZeZnEI5BxY_8G6zHND6drQs-rqVYBtkpdLYDfXa0YWqc_33DKjOOSJxvqwJ4zK8zzq1vYhXNskO6cCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQA_K9ZWyHJCZBdA14SKEsTiaYLW4w86XMp5-DEKX_U5aZMEUjDvfZn3vVemCB49pZDeIgAr2fDjalO0rRFNnyfyfbG7mkJJ51h6tPxiomghCpkhnJ69pq4z6r9YyKW4ua1rmCqVVLx8OXkULUV4SrERLSh6NINVu8p_zNum-I-NdUB1sZSEOJL0TJeACDaO6SPMvq90P1qCS6ep0wbNBUHNttIqlKBH-nHlhVQMZtCQ8BYl1Hukvrl8Y5Lu6vZgKJ_x4DxYWHZr-Ojc3ZYaARe8knzx0V6v0uDYd81dicF1etrndCy6v44Cagb0Nv9xFn_FwRB_0546vksjoyGQ1_B1"\n}'
2020-09-29 08:12:05,107:DEBUG:acme.client:Sending POST request to https://acme.digicert.com/v2/acme/finalize/rRZ0hJ1XO4bu1TEQQzOHl4EG2DnAEOnq_30GuUwbF6c/h-OSXC0Ktyhc5gN17nFN9y5nDd_si75AcfwetSNk4S8:
{
"protected": "eyJhbGciOiAiUlMyNTYiLCAia2lkIjogImh0dHBzOi8vYWNtZS5kaWdpY2VydC5jb20vdjIvYWNtZS9hY2NvdW50L3JSWjBoSjFYTzRidTFURVFRek9IbDRFRzJEbkFFT25xXzMwR3VVd2JGNmMiLCAibm9uY2UiOiAiSnlpb3VPdnRZU1BOLVdlcHlGZkthQ0owMnF2WXQxbms0d19HYlpVdk5saG9kSFJ3Y3pvdkwyVnVjbTlzYkcxbE1ESXVjSEp2WkM1aWJIVXVaR2xuYVdObGNuUXVZMjl0T2pnME5ETSIsICJ1cmwiOiAiaHR0cHM6Ly9hY21lLmRpZ2ljZXJ0LmNvbS92Mi9hY21lL2ZpbmFsaXplL3JSWjBoSjFYTzRidTFURVFRek9IbDRFRzJEbkFFT25xXzMwR3VVd2JGNmMvaC1PU1hDMEt0eWhjNWdOMTduRk45eTVuRGRfc2k3NUFjZndldFNOazRTOCJ9",
"signature": "VMRgZ6MTn7r1mrcooyMtAgY_B8BvgT0BlWY0pex3yeMpCrguL_zyHrMDc3vrHjER5ACltBl3GOygJU13S-wO82Wfg7uK-HOmOtNYAH_yH6fmoTNyrZxQMnpiOwwhXQvqLuM3t3iw9usHGlZohJ1TuZ2fbeG93W2egbRmvzz2AEb_wp0Z3u4HXHHAWAeECdlGzOrP7yxpltrFNlf0BK_LR1JFhSxzZLSefEMg80lTFN1fIkHD9QdPmBMO6NAugUxorxzqSwwYTM2YDgF4B8YCQFV57X56GUjWn4z3YpBIH5Vi92UqwZ6cU6arcsDTFmDe7YvG29b9fyxQd3eDNyLeYQ",
"payload": "ewogICJjc3IiOiAiTUlJQzlqQ0NBZDRDQVFBd2diQXhIakFjQmdOVkJBTU1GV0pzYjJjdWEyOXVhV05oYldsdWIyeDBZUzUxY3pFTE1Ba0dBMVVFQmhNQ1ZWTXhFekFSQmdOVkJBZ01DazVsZHlCS1pYSnpaWGt4RHpBTkJnTlZCQWNNQmxKaGJYTmxlVEUzTURVR0ExVUVDZ3d1UzI5dWFXTmhJRTFwYm05c2RHRWdRblZ6YVc1bGMzTWdVMjlzZFhScGIyNXpJRlV1VXk1Qkxpd2dTVzVqTGpFaU1DQUdBMVVFQ3d3WlZHVmphRzVwWTJGc0lFMXBaR1JzWlhkaGNtVWdVM1pqY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTEptS2xNUml6aGFkb0dEamRMSmo1SHluNmZzR3F3N1BtTDVwRXhpRDM2YzUyNUJNR0ItYllzTV9VNmNvak1QT3JtWU9aNGFUWHZMcWw2T2RtQ2F2RngteUpKaW0zWkd2eUk3SGRSb3I1bkVvYTZ2bGV4OFRma3VrRVBJSGFnTXZOTkR1bkc0ZS1jVWJOdmRMUG9FZ0l3OEZ4VWszcVp3M01ZMERDWEhmbW1YQWRuTmpVTmtGS2xFbkVkcHA0UlA0VlFrVGZybWRnMXR4dFZOSzNiVTlEbFRkQnBNMVZZOGh0VHE1M3ZEWGp6MnJ1QmpFM3Jpa1dSZG9yQ1JNNllla1B3N21sNEk0WFplWm5FSTVCeFlfOEc2ekhORDZkclFzLXJxVllCdGtwZExZRGZYYTBZV3FjXzMzREtqT09TSnh2cXdKNHpLOHp6cTF2WWhYTnNrTzZjQ0F3RUFBYUFBTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFBX0s5Wld5SEpDWkJkQTE0U0tFc1RpYVlMVzR3ODZYTXA1LURFS1hfVTVhWk1FVWpEdmZabjN2VmVtQ0I0OXBaRGVJZ0FyMmZEamFsTzByUkZObnlmeWZiRzdta0pKNTFoNnRQeGlvbWdoQ3BraG5KNjlwcTR6NnI5WXlLVzR1YTFybUNxVlZMeDhPWGtVTFVWNFNyRVJMU2g2TklOVnU4cF96TnVtLUktTmRVQjFzWlNFT0pMMFRKZUFDRGFPNlNQTXZxOTBQMXFDUzZlcDB3Yk5CVUhOdHRJcWxLQkgtbkhsaFZRTVp0Q1E4QllsMUh1a3ZybDhZNUx1NnZaZ0tKX3g0RHhZV0haci1PamMzWllhQVJlOGtuengwVjZ2MHVEWWQ4MWRpY0YxZXRybmRDeTZ2NDRDYWdiME52OXhGbl9Gd1JCXzA1NDZ2a3Nqb3lHUTFfQjEiCn0"
}
2020-09-29 08:12:05,170:DEBUG:urllib3.connectionpool:https://acme.digicert.com:443 "POST /v2/acme/finalize/rRZ0hJ1XO4bu1TEQQzOHl4EG2DnAEOnq_30GuUwbF6c/h-OSXC0Ktyhc5gN17nFN9y5nDd_si75AcfwetSNk4S8 HTTP/1.1" 403 118
2020-09-29 08:12:05,170:DEBUG:acme.client:Received response:
HTTP 403
Server: nginx
Date: Tue, 29 Sep 2020 12:12:05 GMT
Content-Type: application/problem+json
Content-Length: 118
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
Replay-Nonce: 7gWZtgNzq78rkKdMLKMpe2vzxvke1WJTlMwqTnkNMqFodHRwczovL2Vucm9sbG1lMDIucHJvZC5ibHUuZGlnaWNlcnQuY29tOjg0NDM
X-Correlation-Id: A0E33315-EADA-B91E-CE38-964A30659A7F
X-Hostname: enrollme02.prod.blu.digicert.com
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

{"detail":"CSR includes different number of names than specifies in the order: ","status":403,"type":"unauthorized"}
2020-09-29 08:12:05,185:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "D:\obj\windows-release\37win32_Release\msi_python\zip_win32\runpy.py", line 193, in _run_module_as_main
File "D:\obj\windows-release\37win32_Release\msi_python\zip_win32\runpy.py", line 85, in run_code
File "D:\jobs\Certbot\bin\certbot.exe_main
.py", line 33, in
sys.exit(main())
File "d:\jobs\Certbot\pkgs\certbot\main.py", line 15, in main
return internal_main.main(cli_args)
File "d:\jobs\Certbot\pkgs\certbot_internal\main.py", line 1357, in main
return config.func(config, plugins)
File "d:\jobs\Certbot\pkgs\certbot_internal\main.py", line 1223, in certonly
cert_path, fullchain_path = _csr_get_and_save_cert(config, le_client)
File "d:\jobs\Certbot\pkgs\certbot_internal\main.py", line 1142, in _csr_get_and_save_cert
cert, chain = le_client.obtain_certificate_from_csr(csr)
File "d:\jobs\Certbot\pkgs\certbot_internal\client.py", line 293, in obtain_certificate_from_csr
fetch_alternative_chains=get_alt_chains)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 925, in finalize_order
return self.client.finalize_order(orderr, deadline, fetch_alternative_chains)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 752, in finalize_order
self._post(orderr.body.finalize, wrapped_csr)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 97, in _post
return self.net.post(*args, **kwargs)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 1201, in post
return self._post_once(*args, **kwargs)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 1214, in _post_once
response = self._check_response(response, content_type=content_type)
File "d:\jobs\Certbot\pkgs\acme\client.py", line 1072, in _check_response
raise messages.Error.from_json(jobj)
acme.messages.Error: unauthorized :: CSR includes different number of names than specifies in the order:
2020-09-29 08:12:05,185:ERROR:certbot._internal.log:An unexpected error occurred:
2020-09-29 08:12:05,185:ERROR:certbot._internal.log:acme.messages.Error: unauthorized :: CSR includes different number of names than specifies in the order:

1 Like

How did you create the CSR file?

2 Likes

I ran:
openssl req -new -newkey rsa:2048 -nodes -keyout d:\apache_files\ssl%1_%tstamp%.key -out d:\apache_files\requests%1_%tstamp%.csr -subj "/CN=%1/C=US/ST=New Jersey/L=Ramsey/O=Konica Minolta Business Solutions U.S.A., Inc./OU=Technical Middleware Svcs"

I also tried IBM's ikeyman java gui which creates a csr for another domain, but getting similar errors. Both csrs check out ok with digicert csr checker https://ssltools.digicert.com/checker/views/csrCheck.jsp

I'm not sure I follow your "plan".
If you intend on using the local webroot, and use the default authentication method (HTTP), then all those names will need to resolve to your host IP.
If you want to run certbot from a completely unrelated IP, there is no CSR file that can be used to bypass authentication. The only validation method left is DNS.

2 Likes

So, I'd have to install certbot on all the servers? It could be 100 servers, which I may or may not have access to. There's no way to "proxy" or use another authentication or prove ownership method?

1 Like

I am not 100% sure about how DigiCert does validation...
[which you might be doing with the included --eab parameters]
So you would need to confirm with them "how to" validate properly first.
If that is their "offline" validation method, then the --webroot is completely unnecessary.
But that would still leaves the:

Here, again, you would have to confirm with DigiCert their method of creating orders and matching CSRs.
All the examples I could find for "certbot and digicert" included "-d FQDN".
[again, not certain about anything DigiCert]

2 Likes

It sounds to me like there are extra domain names in the CSR that aren't specified on the order. Seems like a redundant process of specifying domain names to certify to the CA then submitting a CSR to the CA that then matches the specified domains against the domains in the CSR. If they don't match... kaboom! :firecracker:

1 Like

Well, with the IBM gui ikeyman, it is creating a server key when you create the CSR. Once you have the key, you "receive" it into the gui where it matches it with the key. It is then available in the certificate store for use. Conceivably, I could just renew it, but I want to do a new key / csr.

It's odd that I get same error with an openssl csr as well. Digicert support just refers me to documentation. Their cert checker says the csr is ok for both IBM and OpenSSL csr. I got openssl to work with Let's Encrypt.

Perhaps you're not specifying all of the domains on the Digicert order (or specifying extras)?

1 Like

I worked with someone from Digicert and changed to certonly and -d mydomain.com and it's working... It creates a private key, which I would prefer to create.

1 Like

Glad you got it working. :slightly_smiling_face:

Generation of the underlying CSR always results in generation of a private key (unless you choose to reuse an existing private key, which is inadvisable).

2 Likes

At least you have a working (starting) point.
From there you should be able to move forward and incorporate your own private keys.
[I use my own keys all the time]

2 Likes

In Certbot, once you have a key with a non-CSR method, you can continue using that key (for subsequent certificate renewals) with the --reuse-key option.

If you really need to use a key that you already created externally, you can create a new certificate with a Certbot-generated key and then copy your own private key into /etc/letsencrypt/archive/your-cert-name/privkey.pem. This is extremely risky because if Certbot needs to restart the webserver while requesting your new certificate, and your webserver objects to the mismatch between your existing certificate and your manually-generated key, it might not restart properly and might get into a hard-to-fix state. So, I would not recommend using this workaround, and possibly shouldn't even have mentioned it. :slight_smile:

2 Likes

@schoen

:astonished:

You talked about private key club.
You should never talk about private key club.

1 Like