Martin, this was extremely helpful. I got it to work manually, now all I need to do is automate the process :-)
The only thing "missing" from this is that I needed to do "ipa host-add san.host.example.test" before your other "ipa service-add" commands . You mentioned it, but not shown the command, so for those who will want to follow the script, it is an essential part of the process. Thank you so much, -M On Mon, Sep 15, 2014 at 7:53 AM, Martin Kosek <[email protected]> wrote: > On 09/12/2014 09:19 PM, Dmitri Pal wrote: > > On 09/12/2014 02:43 PM, Michael Lasevich wrote: > >> That is awesome, but I am clearly missing some insight as to how this is > >> supposed to work. Can you point me to some more specific info on how to > >> accomplish this. > >> > >> I tried using the ipa-getcert request with multiple -D's from the > client, but > >> got : > >> > >> ** Insufficient access: You need to be a member of the serviceadmin > role to > >> add services > >> > >> Unless I am missing something, I should probably not add each host to > >> "serviceadmins" for security reasons. > > > > 4.0 has a new permissions system this might yet to be another use case > that we > > might have overlooked. > > Not, not really - this part works well with 4.0. > > > I will leave to developers to review this situation on Monday morning. > > > >> > >> So I then I tried generating a csr via openssl with SANs on the client > and > >> then adding it using "ipa cert-request file.csr --prinicple > >> host/${client_hostname}@DOMAIN" from ipa server as admin (just to be > sure) > >> and got this error (where <ALIAS> is the first SAN): > >> > >> ** ipa: ERROR: The service principal for subject alt name <ALIAS> in > >> certificate request does not exist > >> > >> It sounds like I need to create service principal for each SAN, but I > can't > >> seem to figure out how to do it (only allows me to create service > prinicpals > >> for existing hosts) > > You need to create an (unused) host for the SAN service first. After that > you > can create the service. Dummy service/host entries with appropriate > managedby > attribute are used to authorize which host/service. > > I did a quick test with latest FreeIPA 4.0.3 and it worked for me: > > # ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K > test/`hostname` -N > CN=`hostname`,O=EXAMPLE.COM -D san.host.example.test -g 2048 > New signing request "20140915143901" added. > > # ipa-getcert list -i 20140915143901 > Number of certificates and requests being tracked: 8. > Request ID '20140915143901': > status: CA_REJECTED > ca-error: Server at https://ipa.mkosek-fedora20.test/ipa/xml > denied our > request, giving up: 2100 (RPC failed at server. Insufficient access: You > need > to be a member of the serviceadmin role to add services). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > certificate: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert' > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: > track: yes > auto-renew: yes > > > This is expected, now the authorization needs to be added: > > # ipa service-add test/`hostname` > # ipa service-add test/san.host.example.test --force > # ipa service-add-host test/san.host.example.test --host `hostname` > Principal: test/[email protected] > Managed by: san.host.example.test, ipa.mkosek-fedora20.test > ------------------------- > Number of members added 1 > ------------------------- > > > # ipa-getcert resubmit -i 20140915143901 > Resubmitting "20140915143901" to "IPA". > > # ipa-getcert list -i 20140915143901 > Number of certificates and requests being tracked: 8. > Request ID '20140915143901': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > certificate: > type=NSSDB,location='/etc/httpd/nssdb',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST > subject: CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST > expires: 2016-09-15 14:48:01 UTC > dns: san.host.example.test > principal name: test/[email protected] > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: > track: yes > auto-renew: yes > > # certutil -L -d /etc/httpd/nssdb -n Server-Cert > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 11 (0xb) > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: "CN=Certificate Authority,O=MKOSEK-FEDORA20.TEST" > Validity: > Not Before: Mon Sep 15 14:48:01 2014 > Not After : Thu Sep 15 14:48:01 2016 > Subject: "CN=ipa.mkosek-fedora20.test,O=MKOSEK-FEDORA20.TEST" > ... > Name: Certificate Subject Alt Name > DNS name: "san.host.example.test" > ... > > > I also updated > > http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger > with couple hints how that works. > > HTH, > Martin >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
