Issue #1 is caused due to hardcoded port number [1]

An easy fix is to add a new optional flag `--port` with a default value of 8443. This change will not introduce any visible changes to the sysadmin and he/she can use it in a custom env setup.

I am not sure about what causes issue #2 -- SSL error when Root CA is imported into client nss db.

[1] https://github.com/dogtagpki/pki/blob/162974c77723a6169f0d17cce3765ec4e5c61c97/base/server/python/pki/server/__init__.py#L621

Fixed via the following commit:

commit 568dc97667911ee60de4dcca2e99cd11400ca91b (HEAD -> master, upstream/master)
Author: Dinesh Prasanth M K <SilleBille.github.com>
Date:   Wed May 1 13:20:43 2019 -0400

    Add support for non-default ports in Offline Cert renewal tool (#202)
    
    This patch adds an option to be utilized in a
    non-standard environment (ie) allows custom secure ports
    to be specified during the offline cert renewal process.
    
    Signed-off-by: Dinesh Prasanth M K <dmoluguw>


Test Procedure:
===============

The test efforts can be combined with https://bugzilla.redhat.com/show_bug.cgi?id=1696849

Option to test:
---------------

`pki-server cert-create ... -p, --port <port number>` and `pki-server cert-fix ... -p, --port <port number>`

Hi Dinesh,

I have followed steps mentioned in : https://bugzilla.redhat.com/show_bug.cgi?id=1696849#c5

And observed similar behaviour as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1696849#c9

I have tried the second scenario, following are the error logs:

>>> In pki-tomcat logs, following log is observed: 

2021-08-01 00:30:05 [http-nio-8080-exec-4] WARNING: Failed to read product version String. /usr/share/pki/CS_SERVER_VERSION (No such file or directory)
java.io.FileNotFoundException: /usr/share/pki/CS_SERVER_VERSION (No such file or directory)

>>> Command executed :# pki-server cert-fix --ldapi-socket /var/run/slapd-LAB-ENG-RDU2-REDHAT-COM.socket --agent-uid admin --extra-cert 3 --extra-cert 7
INFO: Loading instance: pki-tomcat
INFO: Loading global Tomcat config: /etc/tomcat/tomcat.conf
INFO: Loading PKI Tomcat config: /usr/share/pki/etc/tomcat.conf
.
.
.

INFO: Serial Number: 0xd
INFO: Issuer: CN=Certificate Authority,O=LAB.ENG.RDU2.REDHAT.COM
INFO: Subject: CN=IPA RA,O=LAB.ENG.RDU2.REDHAT.COM
INFO: New cert is available at: /etc/pki/pki-tomcat/certs/7-renewed.crt
INFO: Stopping the instance
INFO: Selftests enabled for subsystems: ca
INFO: Restoring previous LDAP configuration
INFO: Starting the instance with renewed certs
Job for pki-tomcatd failed because a timeout was exceeded.
See "systemctl status pki-tomcatd" and "journalctl -xe" for details.
ERROR: Command: systemctl start pki-tomcatd


>>> After this I am unable to start the pki-tomcat instance.

Based on our Bluejeans conversation, I was trying to debug the issue in your box. I will share my observations here for future reference:

Instance: pki-tomcat
====================
As per our conv, this was created as part of ipa-server-install. I tried to follow all the steps listed here: https://github.com/dogtagpki/pki/blob/master/docs/admin/Offline_System_Certificate_Renewal.md#usage

The pki-tomcat instance got FIXED! The issue was probably coz the directory server's cert was expired and PKI wasn't able to connect to the LDAP. After updating all the certs, the issue got resolved.

Note that I removed internaldb value from password.conf. I'm still not sure why it got added in the first place. To install ipa, I usually run the following command:

`ipa-server-install -U --domain pki.test --realm PKI.TEST -p ${server_password} -a ${server_password} --setup-dns --setup-kra --auto-forwarders`


Instance: pki-tomcat-cert-fix
=============================

The system is up and fully functional at this point. But, I'm unsure why i'm not able to renew the PKI admin cert. I suspect a small issue where I'm missing the obvious. I can take a look tomorrow with a fresh mind or I would appreciate if you can test this scenario in a fresh environment.

--Dinesh

I have validated cert-fix command in following test scenario :
> Installed idm-server-install : This sets up default ca (pki-tomcat) and ldap 
> Did another pki-tomcat-cert-fix (CA instance on different port than 8443 (20080 / 20443)) installation using pkispawn command.
> Created a certificate with small (~ 1 min) validation period and renewed it using cert-fix command with port and instance option . >>> Worked fine.
> Changed the date to expire system certificates . Only CA Signing Certificate is a valid certificate . I tried to renew all system cert using " pki-server cert-fix --ldapi-socket /var/run/slapd-LAB-ENG-RDU2-REDHAT-COM.socket  --agent-uid caadmin -p 20443 -i pki-tomcat-cert-fix -v " >>> Created new certs for all system certificate.
> PKI Administrator certificate was not renewed by above step so fixed it using --extra-cert option . >>> This has created a new certificate but this certificate could not be used to issue new certificated .

===============================
Observations :
>>> pki-server cert-fix command worked with -p option .
>>> pki-server cert-fix command : In above scenario : If by user runs the "pki-server cert-fix --ldapi-socket /var/run/slapd-LAB-ENG-RDU2-REDHAT-COM.socket  --agent-uid caadmin -p 20443 -v --extra-cert 7"  [Missed -i option]  ::  Then this stops the existing running pki-tomcat instance. 
>>> The PKI Administrator certificate is not the correct ceritificate as this could not be used to create a cert request.
>>> Following are the logs where I tried to import the newly generated PKI Administrator Certificate and use same to generate a cert-request and approve same. >> Approval for this failed
===============================


[root@kvm-01-guest29 ~]# certutil -A -d /root/nssdb -n caadmin_renewed -i /etc/pki/pki-tomcat-cert-fix/certs/6-renewed.crt -c Secret.123 -t "CT,C,C"
Enter Password or Pin for "NSS Certificate DB":
Enter Password or Pin for "NSS Certificate DB":
[root@kvm-01-guest29 ~]# certutil -L -d /root/nssdb  -c Secret.123

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

PKI Administrator for lab.eng.rdu2.redhat.com                u,u,u
caadmin_renewed                                              CTu,Cu,Cu
[root@kvm-01-guest29 ~]#

[root@kvm-01-guest29 ~]# pki -d nssdb/ -c Secret.123 -h `hostname` -p 20080 -n "caadmin_renewed" client-cert-request "uid=test50,cn=test50,o=lab.eng.rdu2.redhat.com" --profile caECServerCert
-----------------------------
Submitted certificate request
-----------------------------
  Request ID: 19
  Type: enrollment
  Request Status: pending
  Operation Result: success
[root@kvm-01-guest29 ~]#
[root@kvm-01-guest29 ~]# pki -d nssdb/ -c Secret.123 -h `hostname` -p 20080 -n "caadmin_renewed" cert-request-review 19 --action=approve
WARNING: pki cert has been deprecated. Use pki ca-cert instead.
WARNING: UNTRUSTED ISSUER encountered on 'CN=kvm-01-guest29.lab.eng.rdu2.redhat.com,OU=pki-tomcat-cert-fix,O=lab.eng.rdu2.redhat.com Security Domain' indicates a non-trusted CA cert 'CN=CA Signing Certificate,OU=pki-tomcat-cert-fix,O=lab.eng.rdu2.redhat.com Security Domain'
Import CA certificate (Y/n)? y
CA server URL [http://kvm-01-guest29.lab.eng.rdu2.redhat.com:8080/ca]: http://kvm-01-guest29.lab.eng.rdu2.redhat.com:20080/ca
PKIException: Unauthorized
[root@kvm-01-guest29 ~]# pki -d nssdb/ -c Secret.123 -h `hostname` -p 20080 -n "caadmin_renewed" cert-request-review 19 --action=approve
WARNING: pki cert has been deprecated. Use pki ca-cert instead.
PKIException: Unauthorized
[root@kvm-01-guest29 ~]#



Attached are the exact logs for above steps.

I have verified cert-create command with -p option . Following are the steps followed :

==============================
A. Setting up a Fake Environment to test cert-create command.
==============================
1. install CA on non standard port (secure port is assumed to be 20443)

2. Submit a caadmin renewal request:  
`pki -d . -c Secret123 ca-cert-request-submit --profile caManualRenewal --serial 0x6 --renewal`

3. Before approving the renewal request, set the validity of the new admin such that there is a period where ALL certs will be valid (as we discussed over phone). I find it easier to do it via browser:
a. import pkcs12 file into browser
b. visit SSL agent services and authenticate using the cert that was imported in step 3a.
c. List the "Pending Renewal Requests" and click on the renewal request that is pending.
d. Set the validity such that the new cert is valid for 11 months

4. Now, set the system date where ALL CERTS ARE VALID

6. Create a new user caadmin2 with same membership as that of caadmin
5. Import the new caadmin cert into LDAP:
`pki -d . -c Secret123 -n caadmin ca-user-cert-add caadmin2 --serial 0x9`

verify whether the import was successful: `pki -d . -c Secret123 -n caadmin2 ca-user-cert-find caadmin`

6. Import the new caadmin cert into NSS DB:
`pki -d . client-cert-import caadmin2 --serial 0x9`

verify whether the import was successful. You should see a new entry: `certutil -L -d .`


============
B. Testing `cert-create`
============

1. Follow steps system certs to https://github.com/dogtagpki/pki/blob/master/docs/admin/Offline_System_Certificate_Renewal.md#manual-renewal-process.
2. The new PKI admin cert generated in Steps A used for certificate management operations.


Detailed test steps are mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1679480#c10

Shalini's analysis (sent by email; reflecting here; my own comments to follow in separate BZ comment):

I have been testing a bugzilla [1679480] on pki-server cert-fix tool along                                             
with Dinesh. And have an observation :                                                                                 
*cert-fix tool is not fixing PKI Administrator certificate in standalone                                               
pki environment* as mentioned in                                                                                       
*https://bugzilla.redhat.com/show_bug.cgi?id=1679480#c7                                                                
<https://bugzilla.redhat.com/show_bug.cgi?id=1679480#c7>*.                                                             
                                                                                                                       
*Scenario is as follows :*                                                                                             
> My all certs except CA Signing Certificate have been expired, as rest all                                            
system certs (including PKI Administrator Certificate) have same validation                                            
period if CA instance is installed using pkispawn command.                                                             
> I tried to use cert-fix  to fix the certificates using following method :                                            
  https://github.com/dogtagpki/pki/blob/master/docs/admin/Offline_System_Certificate_Renewal.md#standalone-pki-environment-uses-ldaps                                                                                                        
                                                                                             
                                                                                                                       
> Above command creates a new certificate for each system certificate and specified extra-cert.                        
                                                                                                                       
> It creates a PKI Administrator cert also but this cert does not work well as it does not have proper admin rights.   
                                                                                                                       
> So my system is in a state where it does not have any valid admin certs to perform certificate management operations.
                                                                                                                       
                                                                                                                       
*As a work around:*                                                                                                    
                                                                                                                       
> I have created a copy of PKI Administrator with a larger validity before expiring my all system certs, And assign    
+this cert to a user with same membership as that of caadmin user.                                                     
                                                                                                                       
*Problem is :* If this backup PKI Administrator cert is not present in                                                 
pure PKI environment , how does my system get an PKI Administrator                                                     
certificate. Please suggest me a way by which i can use this newly                                                     
generated PKI Administrator cert to do certificate management                                                          
operations.In IPA environment.                                                                                         
ipa-cert-fix tool fixes admin certs also in IPA environment.

The nub of the issue is:

> It creates a PKI Administrator cert also but this cert does not work well as it does not have proper admin rights.

The agent/admin certificate specified by --extra-cert was renewed, but not installed in the userCertificate
attribute of the user entry.  That is how authentication is performed - not just having a valid cert, but
the certificate also appearing in the corresponding user entry.

The cert-fix tool has no special provision for this scenario.  But as you point out, if system certs have
expired, there's a good chance agent cert did too.  So we need to make some provision for this, either
in the tool or in documentation.

The fact that cert-fix did complete means that the operation has permission to add the cert to LDAP manually,
either

a) via LDAPI (the simple case); or
b) via LDAPS using subsystem certificate for authentication (yuck!)

In your case you used LDAPI, so the solution is something like:

# openssl x509 -inform PEM -outform DER < /path/to/cert.pem > /path/to/cert.cer
# cat <<EOF > addcert.ldif
dn: uid=admin,ou=people,o=ipaca
changetype: modify
replace: userCertificate
userCertificate:< file:///path/to/cert.cer
EOF
# ldapmodify -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-IPA-LOCAL.socket -f addcert.ldif

(with relevant adjustments for file path, admin/agent uid)


The solution using the subsystem certificate for authentication to LDAP is similar but will
require the mozldap tools, e.g.:

# /usr/lib64/mozldap/ldapmodify -Z \
    -P /etc/pki/pki-tomcat/alias \
    -W $(grep ^internal= /etc/pki/pki-tomcat/password.conf | cut -d = -f 2) \
    -N "subsystemCert cert-pki-ca" \
    -f /path/to/ldif

However, the mozldap tools are no longer available in RHEL.  Which means that you need to use
the 'cn=Directory Manager' account (and password authentication) to add the certificate.

This bug have been verified on RHEL8.1 with following packages and -p option is working as expected with cert-fix and cert-create.

python3-pki-10.7.1-2.module+el8.1.0+3386+52d02a00.noarch
pki-server-10.7.1-2.module+el8.1.0+3386+52d02a00.noarch
pki-base-10.7.1-2.module+el8.1.0+3386+52d02a00.noarch
pki-servlet-4.0-api-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
pki-tools-10.7.1-2.module+el8.1.0+3386+52d02a00.x86_64
pki-ca-10.7.1-2.module+el8.1.0+3386+52d02a00.noarch
pki-symkey-10.7.1-2.module+el8.1.0+3386+52d02a00.x86_64
pki-base-java-10.7.1-2.module+el8.1.0+3386+52d02a00.noarch
pki-servlet-engine-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch


Detailed testing observations are mentioned in comment 7 and comment 11.


A new bugzilla have been reported [ https://bugzilla.redhat.com/show_bug.cgi?id=1731344 ] with reference to https://bugzilla.redhat.com/show_bug.cgi?id=1679480#c13.

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:3416

*** Bug 1731344 has been marked as a duplicate of this bug. ***