search

mpeylo / cmpossl

An OpenSSL-based implementation of the Certificate Management Protocol (CMP), defined in IETF RFCs 4210, 4211, and 6712. It is being extended according to the emerging RFCs 'CMP Updates' (CMPv3), 'CMP Algorithms', and 'Lightweight CMP Profile'.
https://github.com/mpeylo/cmpossl/wiki
Other
35 stars 13 forks source link

CMP Password Based Enrollment #189

Closed mikejhathaway closed 5 years ago

mikejhathaway commented 5 years ago

Hello,

I am trying out password based enrollment with a cnf file and keep getting the following:

Warning: no signature-based protection used since -secret is given
CMP INFO: sending ir
CMP INFO: got response
CMP ERROR: 3509B0B5:CMP routines:CMP_PKIMESSAGE_check_received:missing protection:crypto\cmp\cmp_lib.c:1817:

Wireshark reports that incorrect secret, I know the password is ok and am interested in a couple if items:

  1. is the format of my cnf file correct
  2. is it possible to set the owf to sha1?

cnf file

# Default options
[default]
# General information
server = 192.168.161.23:8040
path = cmpv2/SecGWLDN

# Server authentication
trusted = C:/OpenSSL/data/LTERootCA.cer
recipient = "/C=GB/O=ACME Telco Provider/OU=Certification Authorities/CN=LTE Issuing CA"
ignore_keyusage = 1

# Client authentication
# key and cert will not be used for [first]
key = C:/OpenSSL/data/pwd_device_one.key
# cert = C:/OpenSSL/data/pwd_device_one.cer

# Certificate enrollment options
implicitconfirm = 1

# Certificate request options
certout = C:/OpenSSL/data/pwd_device_one_new.cer

# Initial request options
[first]
# Client authentication
ref=SecGWLDN
secret=caPassw0rd

# Generic message options
cmd=ir

# Certificate request options
newkey=$default::key
subject=/CN=username.pki.acme.com

# Renew certificate options
[renew]
# Generic message options
cmd=kur

# Re-key certificate options
[rekey]
# Generic message options
cmd=kur

# Certificate request options
newkey = C:/OpenSSL/data/pwd_device_one_new.key
certout = C:/OpenSSL/data/pwd_device_one_new.cer

Thanks

Mike

DDvO commented 5 years ago

Hello Mike,

the output of the CMP client clearly indicates that the protection of the response message is missing. So the server did not to protect its response, which typically happens when it sends an error message (or other types of negative responses). To see which response you got, set

unprotectederrors = 1

Then the client will have a closer look at error messages and tell you the details sent by the server.

It may be that the server did not like the password-based protection the client sent, but there are also many other opportunities to do mistakes, e.g., using a subject in the cert template not acceptable according to the server's policy. Though the options you set in your config file for the [first] case look reasonable.

The algorithms used by the CMP client for PBM are currently hard-coded to the minimum required by RFC 4210: HMAC-SHA1. Their parameters, e.g., the iteration counts, could be set at library level but not on the CLI. Yet I do not expect problems at this point.

mikejhathaway commented 5 years ago

Hi David,

Many thanks for the reply, the server in my case is logging that the enrolment password that the client is sending is incorrect, the server logs:

Shared Secret Authentication failed: Unable to validate enrolment secret: INCORRECTSECRET (Shared Secret Authentication failed: Unable to validate enrolment secret: INCORRECTSECRET

I added "unprotectederrors = 1" to the config file and this helped me identify that my client authentication section was incorrect, I think I have corrected this, my enrolment password is caPassw0rd, is the Client Authentication section now correct given the server indicates the password is wrong??

# Default options
[default]
# General information
server = 192.168.161.23:8040
path = cmpv2/SecGWLDN

# Server authentication
trusted = C:/OpenSSL/data/LTERootCA.cer
recipient = "/C=GB/O=ACME Telco Provider/OU=Certification Authorities/CN=LTE Issuing CA"
ignore_keyusage = 1

# Client authentication
# key and cert will not be used for [first]
key = C:/OpenSSL/data/pwd_device_one.key
# cert = C:/OpenSSL/data/pwd_device_one.cer

# Certificate enrollment options
implicitconfirm = 1

# Certificate request options
certout = C:/OpenSSL/data/pwd_device_one_new.cer

# Initial request options
[first]
# Client authentication
ref=SecGWLDN
secret=pass:caPassw0rd

# Generic message options
cmd=ir

# Certificate request options
newkey=$default::key
subject=/CN=username.pki.acme.com

# Renew certificate options
[renew]
# Generic message options
cmd=kur

# Re-key certificate options
[rekey]
# Generic message options
cmd=kur

# Certificate request options
newkey = C:/OpenSSL/data/pwd_device_one_new.key
certout = C:/OpenSSL/data/pwd_device_one_new.cer

unprotectederrors = 1

I moved the unprotectederrors = 1 to the top of the config file and the client confirms what both woreshark and the server logs indicate:

C:\OpenSSL\data>openssl cmp -config password_cmp.cnf -section first
CMP INFO: using OpenSSL configuration file 'password_cmp.cnf'
warning: no signature-based protection used since -secret is given
CMP INFO: sending ir
CMP INFO: got response
CMP WARNING: ignoring missing protection of error response
CMP WARNING: received message is not protected
CMP ERROR: 350B109C:CMP routines:send_receive_check:received error:crypto\cmp\cmp_ses.c:214:PKIStatus: rejection; PKIFailureInfo: badRequest; StatusString: "Shared Secret Authentication failed: Unable to validate enrollment secret: INCORRECTSECRET"

I have been able to validate the server is operational as it ships with its own test client and the password I am using does work.

Regards

Mike

DDvO commented 5 years ago

I've meanwhile discussed with with @mpeylo. It turns out that meanwhile the OWF algorithm of the PBM had been updated to SHA256. We suspect that your CMP server cannot handle this and misleadingly reports this as a wrong secret.

I've just extended the effect of the -digest CLI option to set also the OWF (and added a -mac option which allows setting also the MAC algorithm, with the default is still being hmac-sha1).

I ask you to pull the updated sources, re-build, and try again with digest = sha1 in your config file.

mikejhathaway commented 5 years ago

Many Thanks, Got to remember how do rebuild, its been a while :-) Will update you later.. Regard Mike

DDvO commented 5 years ago

I just had to push my changes again because I had forgotten to add the update to the docs. Does the following work for you?

git pull
make
mikejhathaway commented 5 years ago

Thank You, I have to find my notes, my original build environment has been replaced so have to refresh my memory.

mikejhathaway commented 5 years ago

I refreshed bu build and adding digest = sha1 fixed my enrollment, many thanks!!

Another question, what is the coorect configuration to use a subject DN as the reference when enrolling??

My CMP server supports a global reference for every enrollment or a password for individual devices and the enrollment reference in this case needs to be their DN??

Thanks

Mike

DDvO commented 5 years ago

You are welcome. It was good to make the PBM algorithms configurable anyway.

DDvO commented 5 years ago

Concerning the reference (optionally) related to the secret, according to RFC 4210, our CMP client just requires that -refmust be given if no sender name can be determined from the subject DN of the cert specified with the -cert option or else from the -subject option, such that the server can determine the identity to which the secret belongs. Anything more is up to the needs of the server - which (type of) server do you use?

mikejhathaway commented 5 years ago

Hi David, Many Thanks, I have been playing about with the conf file and comparing network traces, it seems I had miss-configured the client. I am now able to enroll using both a global reference an secret as well as an individual reference or DN and Secret.

My Server supports the ability to enroll all CMP devices with a genertic ref and secret or I can create a white list of devices and assign individual passwords. I now have both working..

This is for an Entrust CMP server..

Many Thanks!

Mike

DDvO commented 5 years ago

Hi Mike,

thank you for your further feedback. Very pleased to hear!

So we can close this issue now.

Cheers, David