Bug 1460675 - Certificate management section needs some rework
Certificate management section needs some rework
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Linux_Domain_Identity_Management_Guide (Show other bugs)
7.3
All Linux
high Severity medium
: rc
: ---
Assigned To: Filip Hanzelka
ipa-qe
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-12 07:51 EDT by Thorsten Scherf
Modified: 2017-10-09 09:31 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-09 09:31:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thorsten Scherf 2017-06-12 07:51:25 EDT
Description of problem:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/certifi
cates.html#certificate-request

The first issue is this:

# certutil -R -d path_to_database -a -g key_size -s "CN=server.example.com,O=EXAMPLE.COM" > certificate_request.csr
# ipa cert-request certificate_request.csr --principal=host/server.example.com

This will create a CSR which does not have a dnsName in the X.509 SAN
extension. All Google Chrome browser >= v58 won't be able to verify
such a certificate. Chances are high that other browsers will deprecate
the subject CN name verification soon as well and also require to have
the dnsName SAN extension in the certificate.

The second issue I see is that we need to explain customers how to
create a CSR for a Kerberos principal alias. This was not working in the
past but has been fixed as part of BZ #1400529. The procedure is
different to the one above, because the way the feature has been
implemented is that you can not list the Kerberos alias with the
cert-request --principal option but either have to list the alias as
dnsName or otherName in the X.509 CSR SAN extension and then request the
cert for the canonical principal name rather than the principal alias
name.

We can discuss for details in an later update. 

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

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