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 1549585 - Document owner and permission parameters to getcert
Summary: Document owner and permission parameters to getcert
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: certmonger
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rob Crittenden
QA Contact: ipa-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-27 13:16 UTC by Johan Swensson
Modified: 2020-03-31 19:44 UTC (History)
4 users (show)

Fixed In Version: certmonger-0.78.4-12.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-31 19:44:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1052 0 None None None 2020-03-31 19:44:31 UTC

Description Johan Swensson 2018-02-27 13:16:24 UTC
Description of problem:
The following parameters are not documented in getcert request --help

{"key-owner", 'o', POPT_ARG_STRING, NULL, 'o', _("owner information for private key"), HELP_TYPE_USER},
{"key-perms", 'm', POPT_ARG_STRING, NULL, 'm', _("file permissions for private key"), HELP_TYPE_MODE},
{"cert-owner", 'O', POPT_ARG_STRING, NULL, 'O', _("owner information for certificate"), HELP_TYPE_USER},
{"cert-perms", 'M', POPT_ARG_STRING, NULL, 'M', _("file permissions for certificate"), HELP_TYPE_MODE},


Version-Release number of selected component (if applicable):
certmonger-0.78.4-3

How reproducible:
getcert request --help or ipa-getcert request --help

Steps to Reproduce:
1. getcert request --help or ipa-getcert request --help
2.
3.

Actual results:
The help nor man pages does not mention the the parameters.

Expected results:
Help and and man pages should mention all available parameters.

Comment 5 Mohammad Rizwan 2019-12-06 10:47:44 UTC
version:
certmonger-0.78.4-12.el7.x86_64


[root@master ~]# ipa-getcert request --help
ipa-getcert - client certificate enrollment tool

Usage: ipa-getcert request [options]

Required arguments:
* If using an NSS database for storage:
  -d DIR	NSS database for key and cert
  -n NAME	nickname for NSS-based storage (only valid with -d)
  -t NAME	optional token name for NSS-based storage (only valid with -d)
* If using files for storage:
  -k FILE	PEM file for private key
  -f FILE	PEM file for certificate (only valid with -k)
* If keys are to be encrypted:
  -p FILE	file which holds the encryption PIN
  -P PIN	PIN value

Optional arguments:
* Certificate handling settings:
  -I NAME	nickname to assign to the request
  -G TYPE	type of key to be generated if one is not already in place
  -g SIZE	size of key to be generated if one is not already in place
  -r		attempt to renew the certificate when expiration nears (default)
  -R		don't attempt to renew the certificate when expiration nears
  -T PROFILE	ask the CA to process the request using the named profile or template
  --ms-template-spec SPEC
	 include V2 template specifier in CSR (format: OID:MAJOR-VERSION[:MINOR-VERSION])
  -X ISSUER	ask the CA to process the request using the named issuer
* Parameters for the signing request:
  -N NAME	set requested subject name (default: CN=<hostname>)
  -U EXTUSAGE	set requested extended key usage OID
  -u KEYUSAGE	set requested key usage value
  -K NAME	set requested principal name
  -D DNSNAME	set requested DNS name
  -E EMAIL	set requested email address
  -A ADDRESS	set requested IP address
  -l FILE	file which holds an optional challenge password
  -L PASSWORD	an optional challenge password value
* Bus options:
  -S		connect to the certmonger service on the system bus
  -s		connect to the certmonger service on the session bus
* Other options:
  -B	command to run before saving the certificate
  -C	command to run after saving the certificate
  -F	file in which to store the CA's certificates
  -a	NSS database in which to store the CA's certificates
  -w	try to wait for the certificate to be issued
  -v	report all details of errors
  -o OWNER	owner information for private key
  -m MODE	file permissions for private key
  -O OWNER	owner information for certificate
  -M MODE	file permissions for certificate



[root@master ~]# getcert request --help
getcert - client certificate enrollment tool

Usage: getcert request [options]

Required arguments:
* If using an NSS database for storage:
  -d DIR	NSS database for key and cert
  -n NAME	nickname for NSS-based storage (only valid with -d)
  -t NAME	optional token name for NSS-based storage (only valid with -d)
* If using files for storage:
  -k FILE	PEM file for private key
  -f FILE	PEM file for certificate (only valid with -k)
* If keys are to be encrypted:
  -p FILE	file which holds the encryption PIN
  -P PIN	PIN value

Optional arguments:
* Certificate handling settings:
  -I NAME	nickname to assign to the request
  -G TYPE	type of key to be generated if one is not already in place
  -g SIZE	size of key to be generated if one is not already in place
  -r		attempt to renew the certificate when expiration nears (default)
  -R		don't attempt to renew the certificate when expiration nears
  -c CA		use the specified CA rather than the default
  -T PROFILE	ask the CA to process the request using the named profile or template
  --ms-template-spec SPEC
	 include V2 template specifier in CSR (format: OID:MAJOR-VERSION[:MINOR-VERSION])
  -X ISSUER	ask the CA to process the request using the named issuer
* Parameters for the signing request:
  -N NAME	set requested subject name (default: CN=<hostname>)
  -U EXTUSAGE	set requested extended key usage OID
  -u KEYUSAGE	set requested key usage value
  -K NAME	set requested principal name
  -D DNSNAME	set requested DNS name
  -E EMAIL	set requested email address
  -A ADDRESS	set requested IP address
  -l FILE	file which holds an optional challenge password
  -L PASSWORD	an optional challenge password value
* Bus options:
  -S		connect to the certmonger service on the system bus
  -s		connect to the certmonger service on the session bus
* Other options:
  -B	command to run before saving the certificate
  -C	command to run after saving the certificate
  -F	file in which to store the CA's certificates
  -a	NSS database in which to store the CA's certificates
  -w	try to wait for the certificate to be issued
  -v	report all details of errors
  -o OWNER	owner information for private key
  -m MODE	file permissions for private key
  -O OWNER	owner information for certificate
  -M MODE	file permissions for certificate

parameters can be seen in the help menu. Hence marking the verified.

Comment 7 errata-xmlrpc 2020-03-31 19:44:23 UTC
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-2020:1052


Note You need to log in before you can comment on or make changes to this bug.