Bug 1533216

Fixed in upstream master:

6a13fb01badbf90f390c4673a35218f62be4a415
a1194ad04ec79091695fd4ea1533347936c22262
6e4f0f1dd97f71cd04d7049db55358f0a09226af
d428aed36506fe266b77bec76a7e63274191a2aa
82937af07cb9b09e0b8cd19f02b4eb28cfe8c97f
d0e166134f0c575a0a5e7af914dd29b1e99986bc

Some basic test instructions.

The patches add additional cipher and digests per a more recent SCEP specification.

Notably it adds the ciphers AES128, AES192 and AES256 with AES256 as the default. The previous default was DES. DES3 is also supported.

It adds the digest SHA384 and changed the default from MD5 to SHA256.

dogtag doesn't support the SCEP capabilities method so you need to configure the ciphers and digest on both the client and server.

To test you first have to start by telling certmonger that SCEP is enabled (see also https://www.dogtagpki.org/wiki/SCEP_Setup)

I tested using the dogtag install from an IPA installation. This is sufficient to verify the basics. 

--- CS.cfg.orig 2019-01-29 18:40:23.283238052 -0500
+++ CS.cfg              2019-01-29 18:40:56.784015924 -0500
@@ -38,7 +38,7 @@
 auths.instance.SessionAuthentication.pluginName=SessionAuthentication
 auths.instance.TokenAuth.pluginName=TokenAuth
 auths.instance.flatFileAuth.authAttributes=PWD
-auths.instance.flatFileAuth.deferOnFailure=true
+auths.instance.flatFileAuth.deferOnFailure=false
 auths.instance.flatFileAuth.fileName=/var/lib/pki/pki-tomcat/conf/ca/flatfile.txt
 auths.instance.flatFileAuth.keyAttributes=UID
 auths.instance.flatFileAuth.pluginName=FlatFileAuth
@@ -634,7 +634,7 @@
 ca.scep._006=##
 ca.scep.allowedEncryptionAlgorithms=DES3
 ca.scep.allowedHashAlgorithms=SHA256,SHA512
-ca.scep.enable=false
+ca.scep.enable=true
 ca.scep.encryptionAlgorithm=DES3
 ca.scep.hashAlgorithm=SHA256
 ca.scep.nonceSizeLimit=16

Add the local IP to the authorization file, /var/lib/pki/pki-tomcat/ca/conf/flatfile.txt

UID:192.168.xxx.xxx
PWD:1234

# systemctl restart pki-tomcatd

To increase debug output, create /etc/sysconfig/certmonger with the contents:

OPTS=-d 3

certmonger logs to the journal.

# systemctl restart certmonger

Add the SCEP CA to certmonger

# getcert add-scep-ca -c scep -u http://`hostname`:8080/ca/cgi-bin/pkiclient.exe -I /etc/ipa/ca.crt

Now we need to hard code the default SCEP cipher to DES3.

# systemctl stop certmonger

Sadly there is no CLI to modify options of a CA so you need to do it manually.

Find the CA

# grep scep /var/lib/certmonger/cas/*

Edit the file and add:

scep_cipher=DES3

# systemctl start certmonger

(anything you add to the CA file while certmonger is running will be lost on restart)

Try a request:

# getcert request -c scep -k /etc/pki/tls/private/scep.key -f /etc/pki/tls/certs/scep.crt -g 2048 -L 1234

This should eventually succeed (getcert list -f /etc/pki/tls/certs/scep.crt for status).

For positive testing you only need to focus on what dogtag supports which is DES3 as a cipher and SHA256 and SHA512 as digest (it supports other very lousy
ciphers and digests not worth spending time on and out-of-scope for this).

To ensure that certmonger can use the unsupported ciphers you can set scep_cipher in the certmonger CA configuration and submit a request. It will fail in dogtag but you can look for the failure in the debug log. Look for something like:

java.lang.Exception: P10 encrypted alg is not supported (not DES): {2 16 840 1 101 3 4 1 42}

The cipher OID used for encryption is in the braces (in this case AES256), ignore the not DES part that is just dogtag being confused.

OID cipher list (and values to test):

AES256  2.16.840.1.101.3.4.1.42 
AES192  2.16.840.1.101.3.4.1.22 
AES128  2.16.840.1.101.3.4.1.2 

You should also see this in the certmonger journal output:

certmonger[22574]: 2019-01-29 18:58:07 [22877] SCEP cipher set from configuration to: 'AES256'

On the other hand the unsupported digests don't show up in a reasonable way. Instead they show as:

[dogtag startup]
...
CRSEnrollment: init: mAllowedHashAlgorithm[1]=SHA384
...
[SCEP request]
...
ServletException javax.servlet.ServletException: Hashing algorithm 'null' is not allowed (SHA256,SHA384,SHA512).

So there isn't much of a point in configuring dogtag with the other digest formats. Instead you can confirm via certmonger that it is being used by stopping certmonger and editing the CA again and use the scep_digest variable for the various settings.

Upon restarting certmonger you should see something like this in the journal:

certmonger[22574]: 2019-01-29 18:58:07 [22877] SCEP digest set from configuration to: 'SHA384'

Possible (secure) values are:

SHA256, SHA384, SHA512

When resubmitting a request to test a different configuration this is what I do:

systemctl stop certmonger
<make changes to CA file>
systemctl start certmonger
<wait for churn to finish>
sed s'/^#//' -i /etc/pki/pki-tomcat/ca/flatfile.txt
getcert stop-tracking -f /etc/pki/tls/certs/scep.crt
rm -f /etc/pki/tls/certs/scep.crt /etc/pki/tls/private/scep.key
getcert request -c scep -k /etc/pki/tls/private/scep.key -f /etc/pki/tls/certs/scep.crt -g 2048 -L 1234

Upon successful enrollment using the auth flatfile the entry is commented out by dogtag.

Build used for verification:

[root@qe-blade-10 ~]# rpm -qa certmonger
certmonger-0.78.4-11.el7.x86_64
[root@qe-blade-10 ~]# rpm -qa ipa-server
ipa-server-4.6.5-9.el7.x86_64
[root@qe-blade-10 ~]# 

Followed procedure mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1533216#c11

[root@qe-blade-10 ~]# getcert request -c scep -k /etc/pki/tls/private/scep_new.key -f /etc/pki/tls/certs/scep_new.crt -g 2048 -L 1234
New signing request "20190612115338" added.


[root@qe-blade-10 ~]# getcert list -f /etc/pki/tls/certs/scep_new.crt
Number of certificates and requests being tracked: 11.
Request ID '20190612115338':
	status: NEED_SCEP_DATA
	ca-error: Error reading request, expected PKCS7 data.
	stuck: no
	key pair storage: type=FILE,location='/etc/pki/tls/private/scep_new.key'
	certificate: type=FILE,location='/etc/pki/tls/certs/scep_new.crt'
	signing request thumbprint (MD5): F634E616 5D5E137B BCCBFE27 74BDE448
	signing request thumbprint (SHA1): 9A8D3F5F 4EEE3DC1 A21F31F0 562659A8 925E69C8
	CA: scep
	issuer: 
	subject: 
	expires: unknown
	pre-save command: 
	post-save command: 
	track: yes
	auto-renew: yes


After adding AES256 to the certmonger config

[12/Jun/2019:08:00:50][http-bio-8080-exec-19]: ServletException javax.servlet.ServletException: Could not decode the request.
java.lang.Exception: P10 encrypted alg is not supported (not DES): {2 16 840 1 101 3 4 1 42}
	at com.netscape.cmsutil.scep.CRSPKIMessage.decodeED(CRSPKIMessage.java:791)


Based on above observations marking bugzilla verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2140