Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

14.3. Managing Users and Groups for a CA, OCSP, KRA, or TKS

Many of the operations that users can perform are dictated by the groups that they belong to; for instance, agents for the CA manage certificates and profiles, while administrators manage CA server configuration.
Four subsystems — the CA, OCSP, KRA, and TKS — use the Java administrative console to manage groups and users. The TPS has web-based admin services, and users and groups are configured through its web service page.

14.3.1. Managing Groups
Copia collegamento

14.3.1.1. Creating a New Group
Copia collegamento

  1. Log into the administrative console. 
    pkiconsole https://server.example.com:8443/subsystem_type
    Copy to Clipboard Toggle word wrap
  2. Select Users and Groups from the navigation menu on the left.
  3. Select the Groups tab.
  4. Click Edit, and fill in the group information.
    View larger image
    It is only possible to add users who already exist in the internal database.
  5. Edit the ACLs to grant the group privileges. See Section 14.5.4, “Editing ACLs” for more information. If no ACIs are added to the ACLs for the group, the group will have no access permissions to any part of Certificate System.

14.3.1.2. Changing Members in a Group
Copia collegamento

Members can be added or deleted from all groups. The group for administrators must have at least one user entry.
  1. Log into the administrative console.
  2. Select Users and Groups from the navigation tree on the left.
  3. Click the Groups tab.
  4. Select the group from the list of names, and click Edit.
  5. Make the appropriate changes.
    • To change the group description, type a new description in the Group description field.
    • To remove a user from the group, select the user, and click Delete.
    • To add users, click Add User. Select the users to add from the dialog box, and click OK.

14.3.2. Managing Users (Administrators, Agents, and Auditors)
Copia collegamento

The users for each subsystem are maintained separately. Just because a person is an administrator in one subsystem does not mean that person has any rights (or even a user entry) for another subsystem. Users can be configured and, with their user certificates, trusted as agents, administrators, or auditors for a subsystem.

14.3.2.1. Creating Users
Copia collegamento

After you installed Certificate System, only the user created during the setup exists. This section describes how to create additional users.

Note

For security reasons, create individual accounts for Certificate System users.
14.3.2.1.1. Creating Users Using the Command Line
Copia collegamento
To create a user using the command line:
  1. Add a user account. For example, to add the example user to the CA: 
    # pki -d ~/.dogtag/pki-instance_name/ca/alias/ -c password -n caadmin \
     ca-user-add example --fullName "Example User"
---------------------
Added user "example"
---------------------
  User ID: example
  Full name: Example User
    Copy to Clipboard Toggle word wrap
    This command uses the caadmin user to add a new account.
  2. Optionally, add a user to a group. For example, to add the example user to the Certificate Manager Agents group: 
    # pki -d ~/.dogtag/pki-instance_name/ -p password -n "caadmin" \
     user-add-membership example Certificate Manager Agents
    Copy to Clipboard Toggle word wrap
  3. Create a certificate request:
    • If a Key Recovery Authority (KRA) exists in your Certificate System environment: 
      # CRMFPopClient -d ~/.dogtag/pki-instance_name/ -p password \
     -n "user_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" \
     -v -o ~/user_name.req
      Copy to Clipboard Toggle word wrap
      This command stores the Certificate Signing Request (CSR) in the CRMF format in the ~/user_name.req file.
    • If no Key Recovery Authority (KRA) exists in your Certificate System environment:
      • Create a NSS database directory: 
        # export pkiinstance=ca1
# echo ${pkiinstance}
# export agentdir=~/.dogtag/${pkiinstance}/agent1.dir
# echo ${agentdir}
# pki -d ${agentdir}/ -C ${somepwdfile} client-init
        Copy to Clipboard Toggle word wrap
      • Store the CSR in a PKCS-#10 formatted file specified by the -o option, -d for the path to an initialized NSS database directory, -P option for a password file, -p for a password, and -n for a subject DN: 
        # PKCS10Client -d ${agentdir}/ -P ${somepwdfile} -n "cn=agent1,uid=agent1" -o ${agentdir}/agent1.csr
PKCS10Client: Certificate request written into /.dogtag/ca1/agent1.dir/agent1.csr
PKCS10Client: PKCS#10 request key id written into /.dogtag/ca1/agent1.dir/agent1.csr.keyId
        Copy to Clipboard Toggle word wrap
  4. Create an enrollment request:
    1. Create the ~/cmc.role_crmf.cfg file with the following content: 
      #numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
#Multiple files are supported. They must be separated by space.
input=~/user_name.req

#output: full path for the CMC request in binary format
output=~/cmc.role_crmf.req

#tokenname: name of token where agent signing cert can be found (default is internal)
tokenname=internal

#nickname: nickname for agent certificate which will be used
#to sign the CMC full request.
nickname=PKI Administrator for Example.com

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=~/.dogtag/pki-instance_name/

#password: password for cert8.db which stores the agent
#certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf
      Copy to Clipboard Toggle word wrap
      Set the parameters based on your environment and the CSR format used in the previous step.
    2. Pass the previously created configuration file to the CMCRequest utility to create the CMC request: 
      # CMCRequest ~/cmc.role_crmf.cfg
      Copy to Clipboard Toggle word wrap
  5. Submit a Certificate Management over CMS (CMC) request:
    1. Create the ~/HttpClient_role_crmf.cfg file with the following content: 
      # #host: host name for the http server
host=server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in binary format
input=~/cmc.role_crmf.req

#output: full path for the response in binary format
output=~/cmc.role_crmf.resp

#tokenname: name of token where SSL client authentication cert can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=~/.dogtag/pki-instance_name/

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=PKI Administrator for Example.com

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitCMCFull
      Copy to Clipboard Toggle word wrap
      Set the parameters based on your environment.
    2. Submit the request to the CA: 
      # HttpClient ~/HttpClient_role_crmf.cfg
Total number of bytes read = 3776
after SSLSocket created, thread token is Internal Key Storage Token
client cert is not null
handshake happened
writing to socket
Total number of bytes read = 2523
MIIJ1wYJKoZIhvcNAQcCoIIJyDCCCcQCAQMxDzANBglghkgBZQMEAgEFADAxBggr
...
The response in data format is stored in ~/cmc.role_crmf.resp
      Copy to Clipboard Toggle word wrap
    3. Verify the result: 
      # CMCResponse ~/cmc.role_crmf.resp
Certificates:
    Certificate:
        Data:
            Version:  v3
            Serial Number: 0xE
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=pki-instance_name Security Domain
            Validity:
                Not Before: Friday, July 21, 2017 12:06:50 PM PDT America/Los_Angeles
                Not  After: Wednesday, January 17, 2018 12:06:50 PM PST America/Los_Angeles
            Subject: CN=user_name
...
Number of controls is 1
Control #0: CMCStatusInfoV2
   OID: {1 3 6 1 5 5 7 7 25}
   BodyList: 1
   Status: SUCCESS
      Copy to Clipboard Toggle word wrap
  6. Optionally, to import the certificate as the user to its own ~/.dogtag/pki-instance_name/ database: 
    # certutil -d ~/.dogtag/pki-instance_name/ -A -t "u,u,u" -n "user_name certificate" -i ~/cmc.role_crmf.resp
    Copy to Clipboard Toggle word wrap
  7. Add the certificate to the user record:
    1. List certificates issued for the user to discover the certificate's serial number. For example, to list certificates that contain the example user name in the certificate's subject: 
      pki -d ~/.dogtag/pki-instance_name/ -c password -n caadmin ca-user-cert-find example
-----------------
1 entries matched
-----------------
  Cert ID: 2;6;CN=CA Signing Certificate,O=EXAMPLE;CN=PKI Administrator,E=example@example.com,O=EXAMPLE
  Version: 2
  Serial Number: 0x6
  Issuer: CN=CA Signing Certificate,O=EXAMPLE
  Subject: CN=PKI Administrator,E=example@example.com,O=EXAMPLE
----------------------------
Number of entries returned 1
      Copy to Clipboard Toggle word wrap
      The serial number of the certificate is required in the next step.
    2. Add the certificate using its serial number from the certificate repository to the user account in the Certificate System database. For example, for a CA user: 
      pki -c password -n caadmin ca-user-cert-add example --serial 0x6
      Copy to Clipboard Toggle word wrap
14.3.2.1.2. Creating Users Using the Console
Copia collegamento
To create a user using the PKI Console:
  1. Log into the administrative console. 
    pkiconsole https://server.example.com:8443/subsystem_type
    Copy to Clipboard Toggle word wrap
  2. In the Configuration tab, select Users and Groups. Click Add.
  3. Fill in the information in the Edit User Information dialog.
    View larger image
    Most of the information is standard user information, such as the user's name, email address, and password. This window also contains a field called User State, which can contain any string, which is used to add additional information about the user; most basically, this field can show whether this is an active user.
  4. Select the group to which the user will belong. The user's group membership determines what privileges the user has. Assign agents, administrators, and auditors to the appropriate subsystem group.
  5. Store the user's certificate.
    1. Request a user certificate through the CA end-entities service page.
    2. If auto-enrollment is not configured for the user profile, then approve the certificate request.
    3. Retrieve the certificate using the URL provided in the notification email, and copy the base-64 encoded certificate to a local file or to the clipboard.
    4. Select the new user entry, and click Certificates.
    5. Click Import, and paste in the base-64 encoded certificate.

14.3.2.2. Changing a Certificate System User's Certificate
Copia collegamento

  1. Log into the administrative console.
  2. Select Users and Groups.
  3. Select the user to edit from the list of user IDs, and click Certificates.
  4. Click Import to add the new certificate.
  5. In the Import Certificate window, paste the new certificate in the text area. Include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- marker lines.

14.3.2.3. Renewing Administrator, Agent, and Auditor User Certificates
Copia collegamento

There are two methods of renewing a certificate. Regenerating the certificate takes its original key and its original profile and request, and recreates an identical key with a new validity period and expiration date. Re-keying a certificate resubmits the initial certificate request to the original profile, but generates a new key pair. Administrator certificates can be renewed by being re-keyed.
Each subsystem has a bootstrap user that was created at the time the subsystem was created. A new certificate can be requested for this user before their original one expires, using one of the default renewal profiles.
Certificates for administrative users can be renewed directly in the end user enrollment forms, using the serial number of the original certificate.
  1. Renew the admin user certificates in the CA's end users forms, as described in Section 5.5.1.1.2, “Certificate-Based Renewal”. This must be the same CA as first issued the certificate (or a clone of it).
    Agent certificates can be renewed by using the certificate-based renewal form in the end entities page. Self-renew user SSL client certificate. This form recognizes and updates the certificate stored in the browser's certificate store directly.

    Note

    It is also possible to renew the certificate using certutil, as described in Section 16.3.3, “Renewing Certificates Using certutil”. Rather than using the certificate stored in a browser to initiate renewal, certutil uses an input file with the original key.
  2. Add the renewed user certificate to the user entry in the internal LDAP database.
    1. Open the console for the subsystem. 
      pkiconsole https://server.example.com:admin_port/subsystem_type
      Copy to Clipboard Toggle word wrap
    2. Configuration | Users and Groups | Users | admin | Certificates | Import
    3. In the Configuration tab, select Users and Groups.
    4. In the Users tab, double-click the user entry with the renewed certificate, and click Certificates.
    5. Click Import, and paste in the base-64 encoded certificate.
    This can also be done by using ldapmodify to add the renewed certification directly to the user entry in the internal LDAP database, by replacing the userCertificate attribute in the user entry, such as uid=admin,ou=people,dc=subsystem-base-DN.
When a valid user certificate has already expired, you can no longer use the web service page nor the pki command-line tool requiring authentication. In such a scenario, you can use the pki-server cert-fix command to renew an expired certificate.
Before you proceed, make sure:
  • You have a valid CA certificate.
  • You have root privileges.

Procedure 14.1. Renewing an Expired Administrator, Agent, and Auditor User Certificate

  1. Disable self test.
    • Either run the following command: 
      # pki-server selftest-disable -i PKI_instance
      Copy to Clipboard Toggle word wrap
    • Or remove the following line from CA's CS.cfg file and restart the CA subsystem: 
      selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
      Copy to Clipboard Toggle word wrap
  2. Check the expired certificates in the client's NSS database and find the certificate’s serial number (certificate ID).
    1. List the user certificates: 
      # certutil -L -d /root/nssdb/
      Copy to Clipboard Toggle word wrap
    2. Get the expired certificate serial number, which you want to renew: 
      # certutil -L -d /root/nssdb/ -n Expired_cert | grep Serial
    Serial Number: 16 (0x10)
      Copy to Clipboard Toggle word wrap
  3. Renew the certificate. The local LDAP server requires the LDAP Directory Manager’s password. 
    # pki-server cert-fix --ldap-url ldap://host389 --agent-uid caadmin -i PKI_instance -p PKI_https_port --extra-cert 16
    Copy to Clipboard Toggle word wrap
  4. Re-eanable self test.
    • Either run the following command: 
      # pki-server selftest-enable -i PKI_instance
      Copy to Clipboard Toggle word wrap
    • Or add the following line to CA's CS.cfg file and restart the CA subsystem: 
      selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
      Copy to Clipboard Toggle word wrap
To verify that you have succeeded in the certificate renewal, you can display sufficient information about the certificate by running: 
# pki ca-cert-find
Copy to Clipboard Toggle word wrap
To see full details of the specific certificate including attributes, extensions, public key modulus, hashes, and more, you can also run: 
# pki ca-cert-show 16 --pretty
Copy to Clipboard Toggle word wrap

14.3.2.5. Deleting a Certificate System User
Copia collegamento

Users can be deleted from the internal database. Deleting a user from the internal database deletes that user from all groups to which the user belongs. To remove the user from specific groups, modify the group membership.
Delete a privileged user from the internal database by doing the following:
  1. Log into the administrative console.
  2. Select Users and Groups from the navigation menu on the left.
  3. Select the user from the list of user IDs, and click Delete.
  4. Confirm the delete when prompted.
Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat