RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1461441 - Serial number does not fall in the range when serial number range and random serial number is enabled in the installation file
Summary: Serial number does not fall in the range when serial number range and random ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.4
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Jack Magne
QA Contact: Asha Akkiangady
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-14 12:59 UTC by Roshni
Modified: 2020-10-04 21:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-28 21:49:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2859 0 None None None 2020-10-04 21:32:37 UTC

Description Roshni 2017-06-14 12:59:39 UTC 
Description of problem:
Serial number does not fall in the range when serial number range and random serial number is enabled in the installation file

Version-Release number of selected component (if applicable):
pki-core-10.4.1-8.el7

How reproducible:
always

Steps to Reproduce:
1. pkispawn CA with the following installation file (I was attempting migration)
[root@nocp1 ~]# cat rpattath/ca-migration.cfg 
[DEFAULT]
pki_instance_name=pki-tomcat-ca-rpattath
pki_user=pkiuser
pki_group=pkiuser
pki_audit_group=pkiaudit
pki_https_port=30042
pki_http_port=30044

#NSS DB Token Password
pki_hsm_enable=True
pki_hsm_libfile=/opt/nfast/toolkits/pkcs11/libcknfast.so
pki_hsm_modulename=nfast
pki_token_name=NHSM6000-OCS
pki_token_password=

#Admin Password
pki_admin_password=
pki_client_pkcs12_password=
pki_ds_ldap_port=1604
pki_ds_bind_dn=cn=Database Manager
pki_ds_password=
pki_ds_remove_data=True
pki_existing=True
pki_ds_secure_connection=True
pki_ds_ldaps_port=1605
pki_ds_secure_connection_ca_pem_file=/tmp/ca_cert.pem

[Tomcat]
pki_ajp_port=30009
pki_tomcat_server_port=30005

[CA]
pki_ca_signing_csr_path=/root/rpattath/ca_signing.csr
pki_ca_signing_cert_path=/root/rpattath/ca_signing.crt
pki_ca_signing_nickname=caSigningCert cert-pki-ca-rpattath
pki_ca_signing_token=NHSM6000-OCS
pki_pin=
pki_ds_hostname=nocp1.idm.lab.eng.rdu2.redhat.com
pki_ds_base_dn=dc=nocp9.idm.lab.eng.rdu2.redhat.com-pki-ca-rpattath
pki_ds_database=nocp9.idm.lab.eng.rdu2.redhat.com-pki-ca-rpattath
pki_serial_number_range_start=50
pki_request_number_range_start=100
pki_random_serial_numbers_enable=True
pki_master_crl_enable=False
pki_skip_installation=True

2.
3.

Actual results:
None of the serial numbers of system certs generated after pkispawn falls in the range specified

Expected results:
The random serial number must fall in the range specified

Additional info:
Comment 2 Jack Magne 2017-08-25 01:20:32 UTC 
This issue, is possibly due to an error in the config file.


The following may be the issue:


pki_serial_number_range_start=50
pki_request_number_range_start=100

One setting is for the start of the serial number range and the other is for the start of the request number range. The endpoints of both those ranges will be defaulted to some large number.


I tried the following on my box:


pki_serial_number_range_start=3
pki_serial_number_range_end=20

For some reason the server appears to interpret the serial number range values as hex or base 16. Unfortunately, I haven't been able to determine how to input a direct hex value. What happens is it will accept and integer and it will be interpreted at hex. For instance our 20 will be considered 0x20, which is 32 in decimal.


This would explain the following serial numbers generated for the system certs after ca installation:

Notice they conform to the very skinny range of 3 to 32. This artificial small range is just to prove the server is getting the right values and doing the right things with them.


0x3 	valid 	
CN=CA Signing Certificate,OU=pki-client-auth,O=sjc.redhat.com Security Domain
0x4 	valid 	
CN=PKI Administrator,E=caadmin.com,OU=pki-client-auth,O=sjc.redhat.com Security Domain
0x9 	valid 	
CN=CA OCSP Signing Certificate,OU=pki-client-auth,O=sjc.redhat.com Security Domain
0xd 	valid 	
CN=CA Audit Signing Certificate,OU=pki-client-auth,O=sjc.redhat.com Security Domain
0x10 	valid 	
CN=Subsystem Certificate,OU=pki-client-auth,O=sjc.redhat.com Security Domain
0x1d 	valid 	
CN=dhcp-16-206.sjc.redhat.com,OU=pki-client-auth,O=sjc.redhat.com Security Domain


After verification of this by QE I believe we can close this bug.
Comment 3 Jack Magne 2017-08-28 21:49:49 UTC 
QE agrees to close this for the reasons listed in the previous comment.
Note You need to log in before you can comment on or make changes to this bug.