What is the purpose of challenge password in simple certificate enrollment protocol (SCEP)?
My understanding is that it is used to authenticate devices.
My question is : How it is different from authentication done by using public and private key pairs?
Challenge password is(/may be) used in the enrollment process. As stated in SCEP specification (section 2.3):
PKCS#10 [RFC2986] specifies a PKCS#9 [RFC2985] challengePassword
attribute to be sent as part of the enrollment request. Inclusion of
the challengePassword by the SCEP client is OPTIONAL and allows for
unauthenticated authorization of enrollment requests. The PKCS#7
[RFC2315] envelope protects the privacy of the challenge password.
When utilizing the challengePassword, the server distributes a shared
secret to the requester which will uniquely associate the enrollment
request with the requester. The distribution of the secret must be
private: only the end entity should know this secret. The actual
binding mechanism between the requester and the secret is subject to
the server policy and implementation.
In section 2.5 draft states:
The challengePassword MAY be used to automatically authorize the
request.
SCEP draft states in section 2.8:
SCEP does not specify a method to request certificate revocation.
but when challenge password was used in the enrollment process then:
In order to revoke a certificate, the requester must contact the CA
server operator using a non-SCEP defined mechanism. Although the
PKCS#10 [RFC2986] challengePassword is used by SCEP for enrollment
authorization (see Enrollment authorization (Section 2.3)) this does
not inhibit the CA server from maintaining a record of the
challengePassword to use during subsequent revocation operations as
implied by [RFC2985].
If a certificate is compromised (the private key is stolen, etc.) the
certificate needs to be revoked as it will remain valid till the end of it's
term.
Any administrator with access to a cert can revoke the cert. If a challenge
password was specified during the certificate signing request that password
will be required before the cert can be revoked.
So, it seems the sole purpose of the challenge password is to prevent
revocation by someone without the password.
SCEP is used to issue certificates to devices (mostly in an untrusted network). The admin will generate challenge password and send it to the user via mail. The SCEP server knows about this challenge password. (We can ask SCEP Server to generate a challenge password and give it to the admin which he shares with respective person). When a device requests SCEP server for certificate with this challenge password, the SCEP server can validate the challenge password and issue certificate.
Actually the device makes first request to get CA cert of the server. It validates the CA Cert. Then the device generates private and public key locally which is what, for instance, iOS MDM agent does. Then a CSR (Certificate Signing Request) is sent to the SCEP server with challenge password. The SCEP Server validates challenge password and now signs the device's public key with its private key. The result is the certificate.
Reference:
https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html
Related
I have created a couple of API's and now I have to test them using Fiddler or any certificate friendly tools. The requests which are not having valid certificate must be rejected by the server.
Certificate Background
Here are the two certificate's issues by CA
I have one intermediate public certificate entitled as
MyIntermediate.cer
I have a private certificate for each device which will request my API to fetch data.
I have uploaded public certificate - MyIntermediate.cer to server [Azure APIM]
Now to test the API's, I have to use some tools like Fiddler or Postman or any other tool which supports certificate upload/reading from store
I do not see any options in these tools to upload or read from windows store. Here I need help
I see settings in postman but it seems like not for CA certificates because I do not have key file.
APIM Details
Azure API manager is the service provided by Microsoft. All the request will be processed by APIM. I have uploaded MyIntermediate.cer public certificate to APIM. So, to call GetCustomer someone has to have certificate which is trusted by MyIntermediate.cer.
You need to have "private certificate for each device" along with it's password (if it was saved with one) to make an authenticated call. If you want to rely on APIM's ability to validate certificate chain then you'll indeed need to upload intermediate certificate, and possible root certificate as well if it's not one of the public ones.
I am not sure if we simply validating the client cert is enough, because if someone steal the cert then they can impersonate others, how do we validating the client? Does client needs to sign some message with its private key , send together with the client cert, and server side get the public key from the cert to validate the message to confirm he is the cert holder?
When a server validates a client certificate, it makes the client prove that the certificate is theirs by performing an operation with its corresponding private key. The private key isn't part of the certificate, so stealing it doesn't allow impersonation of the user.
I am trying to implement a (simplified) RSA-like verification process in my (Java) application.
The client sends a request (data + private key signature) and the server either rejects his request or processes it - depending on the signature validity.
But I don't understand how the verification server knows which public key to use for signature decryption. Indeed, no public key - nor public key ID - seem to be sent to the verification server.
Does it actually test all authorized public keys ? Or is the public key stored from a previous communication exchange ?
The figure has several errors and some omissions, because it is probably a simplification:
the hash is digitally signed, not encrypted, and the signature is verified, not decrypted. The underlying cryptographic operation is not equivalent.
the signed data should include the certificate and the certification chain
if you use a known format like CMS, pkcs#7 or XMLDsig the hash to sign usually includes also a reference to the signing certificate and content-type to avoid tampering
To validate a signed document you verify the signature using the public key of the attached certificate but it is mandatory to check that the signing certificate is trusted verifying that the certificate itself or the issuing Certification Authority is present in the client's trustore.
The signature includes the certification chain because usually the truststore does not contain the intermediate CAs. The certificates of the truststore are exchanged previously
Additionaly the verification process should check that the certificate is not expired and not revoked
Note that the verification process is the same for all digital certificates in a public key infrastructure, not just RSA
As the figure you attached with the question suggests, the client sends its certificate along with the signature, the certificate contains the public key, the server checks for certificate validity and uses it to check the signature.
I have an architecture where there is a single root CA and multiple sub-CA's. Each sub-CA publishes certificates for devices in it's "domain". Within each domain is a VPN gateway (Cisco router). I would like to determine if it is possible to devise a configuration where each domain's VPN gateway would be able to check to see if the connecting device's certificate has been revoked at it's domain's sub-CA or another of the other domain's sub-CAs. I'm also looking for the most efficient solution which would require as little configuration as possible when adding new domains.
Thanks!
A CRL or OCSP response has the serial number of the revoked certificate in a list, which is signed by the issuing CA or OCSP responder. This ensures that when I revoke certificate serial no 123456789 on my CA that the certificate with the same serial number but issued by your CA isn't revoked instead. Certificate serial numbers, although long, aren't globally unique.
From a security perspective, the ability to revoke another CA's certificates would just cause mayhem and the consequences would be dire.
The only CA that can revoke a certificate is the one that issued it.
I have a mobile app that will be communicating with my webserver over https. My question is, do I even need to worry about installing a certificate since all traffic to this api will be headless?
In my understanding, SSL provides the encryption for a request, and a certificate establishes trust for the end user. Because these calls to my webserver will essentially be headless, I'm thinking I don't need to worry about the trust establishment.
Am I correct in this thinking?
You will either need a self-signed certificate or a CA-signed certificate in order to use HTTPS on your server.
If your certificate is not assigned to you by a certificate authority, then any connection you make will trigger an error in your URLRequest that you will have to handle. The problem with an untrusted certificate is that a malicious man-in-the-middle could fake data to and from your server with his own self-signed certificate, and possibly pick up authentication credentials or data that he should not have access to.
If you are dealing with any authentication credentials or other private data, I'd recommend just requesting a signed certificate. If you shop around, you can find cheap signed certificates for $10-20 a year, which is a trivial cost to protect your users.
However, if this is just a personal project (the only data you have to worry about is yours), or any data that you will be sending is freely available, a self-signed certificate may be enough.