A Challenge Password For Csr
Claribel Szwaja
The challenge password requested as part of the CSR generation is not the same thing as the passphrase used to encrypt the secret key. The challenge password is basically a shared-secret nonce between you and the SSL certificate-issuing authority, embedded in the CSR, which the issuer may use to authenticate you should that ever be needed.
The "challenge password" requested as part of the CSR generation, is different from the passphrase used to encrypt the secret key (requested at key generation time, or when a plaintext key is later encrypted - and then requested again each time the SSL-enabled service that uses it starts up).
So it should be clear what an encrypted private key (which apache, or any other SSL-enabled server, will need unlocking for it when it starts) and a plaintext private key (which doesn't require unlocking at service start time) look like. Now I'll generate a CSR with a challenge password from the unencrypted key:
So I say again: the "challenge password" requested as part of the CSR generation is not the same thing as a passphrase used to encrypt the secret key. The "challenge password" is basically a shared-secret nonce between you and the SSL certificate-issuer (aka Certification Authority, or CA), embedded in the CSR, which the issuer may use to authenticate you should that ever be needed. Some SSL certificate-issuers make that clearer than others; look down at the bottom of this page to see where they say the challenge password is needed - it's not when you restart apache:
Should you choose to enter and use a challenge password, you will needto make sure that you save that password in a secure place. If youever need to reinstall your certificate for any reason, you will berequired to enter that password.
And what about client's keys? I see that a build-key-pass exists to generate encrypted client keys, but no server equivalent exists. Still, both build-key and build-key-pass ask for a challenge password.
If your CA allows this, then the Challenge Password will be required of anyone who tries to get the cert revoked. -- But from what I understand there are few (or none?) CAs that actually use this. (Please leave a comment if you know otherwise.) So leave it empty if you're unsure.
But if you have a CA that will challenge the rogue admin to supply the "Challenge Password", then the rogue admin may not have that password and then you're safe from that DOS.
(The CP is NOT included in either cert or key. Only in the CSR. And you don't need the CSR for daily operations, so presumably operations personnel might not come into contact with the CSR file and therefore not know the Challenge Password.) (But bear in mind that you still have to worry about a rogue admin who has your cert/key. A lot. So from my understanding you gain exactly nothing from having a "challenge password" in the first place. -- Correct me if I'm wrong. I've got the feeling I'm missing some essential idea here. -- Maybe this is meant to allow revocation by somebody holding just the certificate and the password but NOT the private key.)
The most easy answer for why the empty password is pretty simple. your not going to be around to ENTER said password when the service starts / restarts. and the ONLY way to reliably have the server key work in that scenario is to have an empty key.
The challengePassword attribute type specifies a password by which an entity mayrequest certificate revocation. The interpretation of challenge passwords is intended to bespecified by certificate issuers etc; no particular interpretation is required.
this specifies the section containing any request attributes: its format is the same as distinguished_name. Typically these may contain the challengePassword or unstructuredName types. They are currently ignored by OpenSSL's request signing utilities but some CAs might want them.
Yes, some CAs might want them. I am using NDES windows 2008 r2, it needs challenge password, it looks like it can not be generated by openssl req application, can I use openssl C API or python/perl? Or do I need to fix the openssl code?
To enable challenge password attribute in the CSR, we need to write ASN printable string, but the openssl req utility by default writes MBSTRING_ASC string, so it always return ":unable to print attribute ..."
I have been working on this for days now and still have not been able to make it work correctly. I have built a JAMF profile with payload for SCEP configuration. I have entered the URL, CA Name, Subject and Challenge type (Dynamic-Microsoft CA). I have also entered the correct admin page but when I import the profile to the Mac Device it never makes the challenge request. I see it go through GetCACaps, then GetCACert and finally it tried to make the PKIOperation request but since it never requested a challenge password this fails. I can make the profile work if I use static and manually pull down a challenge password but this isn't a good way to deploy Certificates in an Enterprise environment. I have also opened the .mobileconfig file with a text editor but I don't see the mscep_admin URL defined anywhere. Not sure if anyone has some tips or information that I might have missed that could help me out.
Essentially if you go to http(s)://server/CertSrv/mscep_admin/ you should get the NDES page with the thumbprint for the CA certificate without being prompted for information. This is not ideal in our environment, but it was the only way we could get it to work.
Note: if you get a error on installing the configuration profiles with SCEP that has an error similar to "NSStatusError -67693", you will need to restart IIS on the SCEP/NDES server. Restarting the app pool will not be sufficient.
That is one option that I have thought about if it comes down to it but as you said its not the ideal setup. Should there be an entry for the admin page in the .mobileconfig file? I would think that if you enter that in the JAMF profile that when it writes the file it would have that in there.
Also there is a script that you can run to increase the size of the request filter buffer. By default it is 1024. %systemroot%system32inetsrvappcmd.exe set config /section:system.webServer/security/requestFiltering /requestLimits.maxQueryString:"8192" /commit:apphost
The GETCACAP's isn't an issue for me, I can see the Mac device calls out for the GETCACAP just fine with a valid response. The only issue I have right now is the challenge request to the admin page, if I could figure out why the Mac device isn't making that call for the challenge password then this would finally work.
What was your outcome eploughe? I'm running into the same issue (challenge request rejected) and setting anonymous access won't be an option in my environment. I have had success when manually applying the thumbprint and password, but like you said I can't deploy that way because of the password timeout.
I think the reason you are not seeing the mscep_admin setting is because it is actually the JSS that requests the challenge password from the SCEP server and then populates it in the .mobileconfig that it sends to the client, so if you manually download the .mobileconfig it will just have the variable place holder rather than the value, e.g.:
I think you need to either have APNs setup so that Casper can deploy the profile dynamically OR find some way of populating the variable yourself (i'm guessing the mscep_admin page has some sort of api for Casper to be able to use it).
mdmclient[55034]: ProcessRequestCertSignatureResponse: Cert signature request failed with -909
mdmclient[55034]: Error: Error Domain=NSOSStatusErrorDomain Code=-909 "badReqErr: bad parameter or invalid state for operation"
@mapurcel contact JAMF support. In certain configurations, they provide a different JAR file for the MS SCEP request stuff. They provided that to me to replace in the webroot of the Tomcat server lib folder, and it solved the 909 errors.
@guidotti thanks for the tip, I brought it to the attention of our rep but the alternative JAR file is for environments running on Windows with Java 7, whereas we are on Linux with Java 6 so the search for a solution continues..
That's interesting, because it took the better part of a year to get ours working.
There is definitely a different JAR file to use for non-java 6, as of the last version of the JSS.
We use Java 8.
It slightly changes the behavior of the scraper.
Jamf's purpose is to simplify work by helping organizations manage and secure an Apple experience that end users love and organizations trust. Jamf is the only company in the world that provides a complete management and security solution for an Apple-first environment that is enterprise secure, consumer simple and protects personal privacy. Learn about Jamf.
This site contains User Content submitted by Jamf Nation community members. Jamf does not review User Content submitted by members or other third parties before it is posted. All content on Jamf Nation is for informational purposes only. Information and posts may be out of date when you view them. Jamf is not responsible for, nor assumes any liability for any User Content or other third-party content appearing on Jamf Nation.
In computer security, challenge-response authentication is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated.[1]
An adversary who can eavesdrop on a password authentication can then authenticate itself by reusing the intercepted password. One solution is to issue multiple passwords, each of them marked with an identifier. The verifier can then present an identifier, and the prover must respond with the correct password for that identifier. Assuming that the passwords are chosen independently, an adversary who intercepts one challenge-response message pair has no clues to help with a different challenge at a different time.
ff7609af8f