[Pkg-freeipa-devel] [Git][freeipa-team/dogtag-pki][upstream] 7 commits: Disabled AIA and cert policy extensions in ACME examples
Timo Aaltonen
gitlab at salsa.debian.org
Mon Aug 24 18:27:31 BST 2020
Timo Aaltonen pushed to branch upstream at FreeIPA packaging / dogtag-pki
Commits:
a5d1c9da by Endi S. Dewata at 2020-08-12T11:18:35-05:00
Disabled AIA and cert policy extensions in ACME examples
The ACME NSS issuer has been modified to disable the AIA and
certificate policy extensions by default since they contain
non-functional URLs that might cause certbot to generate
error messages.
https://bugzilla.redhat.com/show_bug.cgi?id=1868233
- - - - -
a48e731d by Alexander Scheel at 2020-08-12T11:33:32-05:00
Start NSSCertExportCLI
Can be tested with pki nss-cert-export
Signed-off-by: Alexander Scheel <ascheel at redhat.com>
- - - - -
0c6b6e91 by Alexander Scheel at 2020-08-12T11:33:32-05:00
Fix export on FIPS-enabled HSMs
Signed-off-by: Alexander Scheel <ascheel at redhat.com>
- - - - -
2df13c41 by Endi S. Dewata at 2020-08-12T11:33:33-05:00
Fixed cert nickname in NSSDatabase.export_cert_from_db()
The NSSDatabase.export_cert_from_db() has been modified to
no longer prepend the token name to the cert nickname since
the cert nickname obtained from serverCertNick.conf already
contains the token name.
- - - - -
eb28b09f by Endi S. Dewata at 2020-08-12T11:33:33-05:00
Removed blank lines in pki nss-cert-export output
The pki nss-cert-export has been modified to remove the extra
blank lines between certs and at the end of the output.
- - - - -
aeb5d041 by Christina Fu at 2020-08-18T09:31:14-07:00
Bug1629025-DEV doc for: Server-Side Keygen for EE
This patch provides document: ServerSideKeygen.adoc
https://bugzilla.redhat.com/show_bug.cgi?id=1629025
- - - - -
a6bf086a by Endi S. Dewata at 2020-08-18T16:54:40-05:00
Updated version number to 10.9.2
- - - - -
11 changed files:
- base/acme/issuer/nss/ca_signing.conf
- base/acme/issuer/nss/sslserver.conf
- base/common/python/pki/nssdb.py
- base/java-tools/src/com/netscape/cmstools/nss/NSSCertCLI.java
- + base/java-tools/src/com/netscape/cmstools/nss/NSSCertExportCLI.java
- docs/admin/CertificateTransparency.adoc
- + docs/admin/ServerSideKeygen.adoc
- + docs/admin/images/Server-SideKeygenEnroll_approval.png
- + docs/admin/images/Server-SideKeygenEnroll_manual.png
- + docs/admin/images/Server-SideKeygen_LDAP_auth.png
- pki.spec
Changes:
=====================================
base/acme/issuer/nss/ca_signing.conf
=====================================
@@ -1,8 +1,9 @@
basicConstraints = critical, CA:TRUE
subjectKeyIdentifier = hash
-authorityInfoAccess = OCSP;URI:http://ocsp.example.com, caIssuers;URI:http://cert.example.com
keyUsage = critical, digitalSignature, keyCertSign, cRLSign
-certificatePolicies = 2.23.140.1.2.1, @cps_policy
-cps_policy.id = 1.3.6.1.4.1.44947.1.1.1
-cps_policy.CPS.1 = http://cps.example.com
+# authorityInfoAccess = OCSP;URI:http://ocsp.example.com, caIssuers;URI:http://cert.example.com
+
+# certificatePolicies = 2.23.140.1.2.1, @cps_policy
+# cps_policy.id = 1.3.6.1.4.1.44947.1.1.1
+# cps_policy.CPS.1 = http://cps.example.com
=====================================
base/acme/issuer/nss/sslserver.conf
=====================================
@@ -1,10 +1,11 @@
basicConstraints = critical, CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
-authorityInfoAccess = OCSP;URI:http://ocsp.example.com, caIssuers;URI:http://cert.example.com
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
-certificatePolicies = 2.23.140.1.2.1, @cps_policy
-cps_policy.id = 1.3.6.1.4.1.44947.1.1.1
-cps_policy.CPS.1 = http://cps.example.com
+# authorityInfoAccess = OCSP;URI:http://ocsp.example.com, caIssuers;URI:http://cert.example.com
+
+# certificatePolicies = 2.23.140.1.2.1, @cps_policy
+# cps_policy.id = 1.3.6.1.4.1.44947.1.1.1
+# cps_policy.CPS.1 = http://cps.example.com
=====================================
base/common/python/pki/nssdb.py
=====================================
@@ -1351,6 +1351,35 @@ class NSSDatabase(object):
epoch = datetime.datetime.utcfromtimestamp(0)
return (date - epoch).total_seconds() * 1000
+ def export_cert_from_db(self,
+ nickname,
+ output_file,
+ include_chain=False,
+ output_format=None):
+ cmd = [
+ 'pki',
+ '-d', self.directory
+ ]
+
+ if self.password_file:
+ cmd.extend(['-C', self.password_file])
+
+ if self.token:
+ cmd.extend(['--token', self.token])
+
+ cmd.extend(['nss-cert-export'])
+
+ if include_chain:
+ cmd.extend(['--with-chain'])
+
+ if output_format:
+ cmd.extend(['--format', output_format])
+
+ cmd.extend([nickname, output_file])
+
+ logger.debug('Command: %s', ' '.join(map(str, cmd)))
+ subprocess.check_call(cmd)
+
def export_cert(self,
nickname,
pkcs12_file,
@@ -1752,39 +1781,11 @@ class NSSDatabase(object):
shutil.rmtree(tmpdir)
def extract_ca_cert(self, ca_path, nickname):
- tmpdir = tempfile.mkdtemp()
-
- try:
- p12_file = os.path.join(tmpdir, "sslserver.p12")
- password = pki.generate_password()
-
- # Build a chain containing the certificate we're trying to
- # export. OpenSSL gets confused if we don't have a key for
- # the end certificate: rh-bz#1246371
- self.export_pkcs12(p12_file, pkcs12_password=password,
- nicknames=[nickname], include_key=False,
- include_chain=True)
-
- # This command is similar to the one from server/__init__.py..
- # However, to work during the initial startup, we do not
- # specify the cacerts option! This ensures we always get
- cmd_export_ca = [
- 'openssl', 'pkcs12',
- '-in', p12_file,
- '-out', ca_path,
- '-nodes', '-nokeys',
- '-passin', 'pass:' + password
- ]
-
- # Remove CA.crt prior to starting; openssl gets annoyed otherwise.
- if os.path.exists(ca_path):
- os.remove(ca_path)
-
- res_ca = subprocess.check_output(cmd_export_ca,
- stderr=subprocess.STDOUT).decode('utf-8')
- logger.debug('Result of CA cert export: %s', res_ca)
- finally:
- shutil.rmtree(tmpdir)
+ # Build a chain containing the certificate we're trying to
+ # export. OpenSSL gets confused if we don't have a key for
+ # the end certificate: rh-bz#1246371
+ self.export_cert_from_db(nickname, ca_path, include_chain=True,
+ output_format="PEM")
@staticmethod
def __generate_key_args(key_type=None, key_size=None, curve=None):
=====================================
base/java-tools/src/com/netscape/cmstools/nss/NSSCertCLI.java
=====================================
@@ -12,8 +12,9 @@ public class NSSCertCLI extends CLI {
public NSSCertCLI(NSSCLI nssCLI) {
super("cert", "NSS certificate management commands", nssCLI);
+ addModule(new NSSCertExportCLI(this));
addModule(new NSSCertImportCLI(this));
- addModule(new NSSCertRequestCLI(this));
addModule(new NSSCertIssueCLI(this));
+ addModule(new NSSCertRequestCLI(this));
}
}
=====================================
base/java-tools/src/com/netscape/cmstools/nss/NSSCertExportCLI.java
=====================================
@@ -0,0 +1,129 @@
+//
+// Copyright Red Hat, Inc.
+//
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+package com.netscape.cmstools.nss;
+
+import java.io.FileOutputStream;
+import java.nio.file.Files;
+import java.nio.file.Paths;
+import javax.net.ssl.KeyManagerFactory;
+import java.security.cert.X509Certificate;
+
+import org.apache.commons.cli.CommandLine;
+import org.apache.commons.cli.Option;
+import org.apache.commons.io.IOUtils;
+import org.dogtagpki.cli.CommandCLI;
+import org.dogtagpki.nss.NSSDatabase;
+import org.mozilla.jss.pkcs11.PK11Cert;
+import org.mozilla.jss.netscape.security.util.Cert;
+import org.mozilla.jss.netscape.security.util.Utils;
+import org.mozilla.jss.netscape.security.x509.X509CertImpl;
+import org.mozilla.jss.provider.javax.crypto.JSSKeyManager;
+
+import com.netscape.certsrv.client.ClientConfig;
+import com.netscape.cmstools.cli.MainCLI;
+
+public class NSSCertExportCLI extends CommandCLI {
+
+ public static org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(NSSCertExportCLI.class);
+
+ public NSSCertExportCLI(NSSCertCLI nssCertCLI) {
+ super("export", "Export certificate", nssCertCLI);
+ }
+
+ public void printHelp() {
+ formatter.printHelp(getFullName() + " [OPTIONS...] nickname [path]", options);
+ }
+
+ public void createOptions() {
+ Option option = new Option(null, "format", true, "Certificate format: PEM (default), DER, RAW");
+ option.setArgName("format");
+ options.addOption(option);
+
+ option = new Option(null, "with-chain", false, "Export with certificate chain from NSS DB");
+ option.setArgName("with-chain");
+ options.addOption(option);
+ }
+
+ public void execute(CommandLine cmd) throws Exception {
+
+ String[] cmdArgs = cmd.getArgs();
+ String nickname = null;
+ String path = null;
+
+ if (cmdArgs.length < 1) {
+ throw new Exception("Missing required positional argument: nickname");
+ }
+ nickname = cmdArgs[0];
+
+ if (cmdArgs.length >= 2) {
+ path = cmdArgs[1];
+ }
+
+ String format = cmd.getOptionValue("format", "PEM").toUpperCase();
+ boolean chain = cmd.hasOption("with-chain");
+
+ if (!format.equals("PEM") && !format.equals("DER") && !format.equals("RAW")) {
+ throw new Exception("Unknown type of output format: " + format);
+ }
+
+ if (chain && format.equals("DER")) {
+ throw new Exception("Unable to write chain of DER-encoded certificates; use PEM instead.");
+ }
+
+ MainCLI mainCLI = (MainCLI) getRoot();
+ mainCLI.init();
+
+ X509Certificate[] certs;
+
+ KeyManagerFactory kmf = KeyManagerFactory.getInstance("NssX509", "Mozilla-JSS");
+ JSSKeyManager km = (JSSKeyManager) kmf.getKeyManagers()[0];
+
+ if (chain) {
+ certs = km.getCertificateChain(nickname);
+ } else {
+ certs = new X509Certificate[] {
+ (PK11Cert) km.getCertificate(nickname)
+ };
+ }
+
+ byte[] output = null;
+
+ if (format.equals("RAW")) {
+ StringBuffer buffer = new StringBuffer();
+ for (X509Certificate cert : certs) {
+ buffer.append(cert.toString());
+ }
+
+ output = buffer.toString().getBytes();
+ } else if (format.equals("PEM")) {
+ StringBuffer buffer = new StringBuffer();
+
+ for (X509Certificate cert : certs) {
+ byte[] encoded = cert.getEncoded();
+ buffer.append(Cert.HEADER);
+ buffer.append("\r\n");
+ buffer.append(Utils.base64encodeMultiLine(encoded));
+ buffer.append(Cert.FOOTER);
+ buffer.append("\r\n");
+ }
+
+ output = buffer.toString().getBytes();
+ } else if (format.equals("DER")) {
+ for (X509Certificate cert : certs) {
+ output = cert.getEncoded();
+ }
+ }
+
+ if (path == null) {
+ System.out.print(new String(output));
+ System.out.flush();
+ } else {
+ try (FileOutputStream fos = new FileOutputStream(path)) {
+ fos.write(output);
+ }
+ }
+ }
+}
=====================================
docs/admin/CertificateTransparency.adoc
=====================================
@@ -1,8 +1,10 @@
= Certificate Transparency
+Christina Fu <cfu at redhat.com>
+:toc:
== Overview
-A basic version of Certificate Transparency (CT) V1 support (rfc 6962) is offered in this release. It has the capability of issuing certificates with embedded Signed Certificate Time stamps (SCTs) from any trusted log where each deployment site chooses to have its root CA cert included. The system can also be configured to support multiple CT logs. Minimum of one trusted CT log is required for this feature to work.
+A basic version of Certificate Transparency (CT) V1 support (rfc 6962) is offered since PKI 10.9. It has the capability of issuing certificates with embedded Signed Certificate Time stamps (SCTs) from any trusted log where each deployment site chooses to have its root CA cert included. The system can also be configured to support multiple CT logs. Minimum of one trusted CT log is required for this feature to work.
IMPORTANT: It is the responsibility of the deployment site to establish its trust relationship with a trusted CT log server.
=====================================
docs/admin/ServerSideKeygen.adoc
=====================================
@@ -0,0 +1,177 @@
+= ServerSide Key Generation for EE
+Christina Fu <cfu at redhat.com>
+:toc:
+:imagesdir: images
+
+== Overview
+
+Many newer versions of browsers, including Firefox v69 and up, as well as Chrome, have removed the functionality to generate PKI keys and the support for CRMF for key archival. While CLIs such as CRMFPopClient (see "CRMFPopClient --help") or pki (see "pki client-cert-request --help") could be used as a workaround on the Fedora or RHEL platforms, clients on other platforms have been largely left out.
+
+Server-Side Keygen enrollment has been around for a long time since the introduction of Token Key Management System (TMS), where keys could be generated on KRA instead of locally on smart cards. Starting from PKI v.10.5, we adopt a similar mechanism to resolve the browser keygen deficiency issue. Keys are generated on the server (KRA to be specific) and then transferred securely back to the client in PKCS#12.
+
+NOTE: It is highly recommended that the Server-Side Keygen mechanism only being employed for encryption certificates.
+
+== Functionality Highlights
+
+* Certificate request keys are generated on KRA (Note: KRA must be installed to work with the CA)
+* The profile default plugin, serverKeygenUserKeyDefaultImpl, provides selection to enable or disable key archival (i.e. the “enableArchival” parameter)
+* Support for both RSA and EC keys
+* Support for both manual (agent) approval and automatic approval (e.g. directory password-based)
+
+== Installation configuration
+
+NOTE: A KRA instance is required in addition to the CA for setting up Server-Side Keygen.
+
+NOTE: In the case when the CA and KRA are sharing a Tomcat instance, there is no need to execute the above step to import the transport certificate.
+
+After installing CA and KRA instances, in the case of stand-alone Tomcat web server instances, you’d need to add the KRA’s transport cert to the CA’s nssdb.
+
+First, shut down CA
+
+[literal]
+Systemctl stop pki-tomcatd@<ca_instance_name>.service
+e.g.
+# Systemctl stop pki-tomcatd at pki-ca.service
+
+Export KRA’s transport certificate into a file
+
+* Find and export KRA transport cert:
+
+[literal]
+grep "kra.transport.cert=" /var/lib/pki/<kra_instance_name>/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > <kra transport cert file>
+e.g.
+# grep "kra.transport.cert=" /var/lib/pki/pki-kra/kra/conf/CS.cfg | sed 's/kra.transport.cert=//' > /tmp/kraTransport.cert
+
+Import KRA’s transport cert into CA’s nssdb, using the nickname specified in CA’s CS.cfg
+
+* List the transport cert nickname:
+
+[literal]
+grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/<ca_instance_name>/ca/conf/CS.cfg
+e.g.
+# grep "ca.connector.KRA.transportCertNickname" /var/lib/pki/pki-ca/ca/conf/CS.cfg
+ca.connector.KRA.transportCertNickname=KRA transport cert
+
+* Import using the nickname listed from above step:
+
+[literal]
+certutil -d /var/lib/pki/<ca_instance_name>/alias -A -t “,,” -n <transportNickName> -i <kra transport cert file>
+e.g.
+# certutil -d /var/lib/pki/pki-ca/alias -A -t “,,” -n "KRA transport cert" -i /tmp/kraTransport.cert
+
+Start CA
+
+[literal]
+systemctl start pki-tomcatd@<ca_instance_name>.service
+e.g.
+# Systemctl start pki-tomcatd at pki-ca.service
+
+== Profile Configuration
+
+Two default profiles, *_caServerKeygen_UserCert_* and *_caServerKeygen_DirUserCert_*, are provided by default to allow for certificate enrollments where keys are generated on the server side. However, any profile with the right input, output, and policy set could be turned into a server-side keygen profile.
+
+A Server-Side Keygen profile must contain the following components.
+
+=== Input
+
+[literal]
+input.i1.class_id=serverKeygenInputImpl
+
+=== Output
+
+[literal]
+output.o1.class_id=pkcs12OutputImpl
+
+=== Policyset
+
+Key type and key size parameters can be configured as exemplified below:
+
+[literal]
+policyset.userCertSet.3.constraint.class_id=keyConstraintImpl
+policyset.userCertSet.3.constraint.name=Key Constraint
+policyset.userCertSet.3.constraint.params.keyType=-
+policyset.userCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096,nistp256,nistp384,nistp521
+policyset.userCertSet.3.default.class_id=serverKeygenUserKeyDefaultImpl
+policyset.userCertSet.3.default.name=Server-Side Keygen Default
+policyset.userCertSet.3.default.params.keyType=RSA
+policyset.userCertSet.3.default.params.keySize=2048
+policyset.userCertSet.3.default.params.enableArchival=true
+
+=== Authentication
+
+The two default server-side keygen enrollment profiles different in the authentication mechanism, where
+
+caServerKeygen_UserCert.cfg ::
+ contains empty value to *"auth.class_id="*, meaning that enrollment requests through this profile will require approval from a CA agent..
+caServerKeygen_DirUserCert.cfg ::
+ contains *"auth.instance_id=UserDirEnrollment"*, meaning that the user is required to pass LDAP uid/password authentication; Such authentication mechanism is considered as an automatic certificate issuance as it does not require per-request approval from a CA agent.
+
+Automatic approval could be configured by setting the auth.instance_id directive to any compatible authentication plugin class, as examplified in the caServerKeygen_DirUserCert.cfg profile mentioned above. Here is an example of such configuration in CS.cfg:
+
+[literal]
+auths.instance.UserDirEnrollment.dnpattern=
+auths.instance.UserDirEnrollment.ldap.basedn=ou=People,dc=example,dc=com
+auths.instance.UserDirEnrollment.ldap.ldapconn.host=host.example.com
+auths.instance.UserDirEnrollment.ldap.ldapconn.port=389
+auths.instance.UserDirEnrollment.ldap.ldapconn.secureConn=false
+auths.instance.UserDirEnrollment.ldap.maxConns=
+auths.instance.UserDirEnrollment.ldap.minConns=
+auths.instance.UserDirEnrollment.ldapByteAttributes=
+auths.instance.UserDirEnrollment.ldapStringAttributes=mail
+auths.instance.UserDirEnrollment.pluginName=UidPwdDirAuth
+
+== Enrolling a Certificate Using Server-Side Keygen
+
+The default Sever-Side Keygen enrollment profile can be found on the EE page, under the “List Certificate Profiles” tab:
+
+=== Manual User Dual-Use Certificate Enrollment Using server-side Key generation
+
+.Server-Side Keygen Enrollment that requires agent manual approval
+image::Server-SideKeygenEnroll_manual.png[]
+
+=== Directory-authenticated User Dual-Use Certificate Enrollment Using server-side Key generation
+
+.Server-Side Keygen Enrollment that will be automatically approved upon successful LDAP uid/pwd authentication
+image::Server-SideKeygen_LDAP_auth.png[]
+
+Regardless of how the request is approved, the Server-Side Keygen Enrollment mechanism requires the End Entity user to enter a password for the PKCS#12 package which will contain the issued certificate as well as the encrypted private key generated by the server once issued.
+
+IMPORTANT: Users should not share their passwords with anyone. Not even the CA or KRA agents.
+
+When the enrollment request is approved, the PKCS#12 package will be generated and,
+
+* In case of manual approval, the PKCS#12 file will be returned to the CA agent that approves the request; The agent is then expected to forward the PKCS#12 file to the user.
+* In case of automatic approval, the PKCS#12 file will be returned to the user who submitted the request
+
+.Enrollment manually approved by an agent
+image::Server-SideKeygenEnroll_approval.png[]
+
+Once the PKCS#12 is received, the user could use cli such as pkcs12util to import the PKCS#12 file into her/her own user internal cert/key database for each application. E.g. the user’s Firefox nss database.
+
+== Key Recovery
+
+If the *_enableArchival_* parameter is set to *_true_* in the certificate enrollment profile, then the private keys are archived at the time of Server-Side Keygen enrollment. The archived private keys could then be recovered by the authorized KRA agents.
+
+== Additional Information
+
+=== KRA Request Records
+
+NOTE: due to the nature of this mechanism, in case when *_enableArchival_* parameter is set to *_true_* in the profile, there are two KRA requests records per Server-Side keygen request:
+
+* One for request type “asymkeyGenRequest”
+** This request type cannot be filtered at “List Requests” on KRA agent page; One could select “Show All Requests” to see them listed.
+* One for request type “recovery”
+
+=== Audit Records
+
+Some audit records could be observed if enabled:
+
+CA
+
+* SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
+* SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST
+
+KRA
+
+* SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
+* SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED (not yet implemented)
=====================================
docs/admin/images/Server-SideKeygenEnroll_approval.png
=====================================
Binary files /dev/null and b/docs/admin/images/Server-SideKeygenEnroll_approval.png differ
=====================================
docs/admin/images/Server-SideKeygenEnroll_manual.png
=====================================
Binary files /dev/null and b/docs/admin/images/Server-SideKeygenEnroll_manual.png differ
=====================================
docs/admin/images/Server-SideKeygen_LDAP_auth.png
=====================================
Binary files /dev/null and b/docs/admin/images/Server-SideKeygen_LDAP_auth.png differ
=====================================
pki.spec
=====================================
@@ -12,7 +12,7 @@ License: GPLv2 and LGPLv2
# For development (unsupported) releases, use x.y.z-0.n.unstable with alpha/beta phase.
# For official (supported) releases, use x.y.z-r where r >=1 without alpha/beta phase.
-Version: 10.9.1
+Version: 10.9.2
Release: 1%{?_timestamp}%{?_commit_id}%{?dist}
#global _phase -a1
View it on GitLab: https://salsa.debian.org/freeipa-team/dogtag-pki/-/compare/f4b72edb5c703c0a8aae64ae07970407c83f656c...a6bf086a606542e1a0a7c4f832e75d64c4e906b4
--
View it on GitLab: https://salsa.debian.org/freeipa-team/dogtag-pki/-/compare/f4b72edb5c703c0a8aae64ae07970407c83f656c...a6bf086a606542e1a0a7c4f832e75d64c4e906b4
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-freeipa-devel/attachments/20200824/8028feb5/attachment-0001.html>
More information about the Pkg-freeipa-devel
mailing list