Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Bret Wortman]

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and 
see how we go.


Rob, would you have just used the existing "localhost.key" instead of 
generating a new one?



On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually 
going on here. You generate a CSR and call it a certificate. It is 
probably the case that certmonger is ignoring it altogether and 
generating its own CSR.



ipa-getcert list shows it approved. I set up SSL in apache to use the
above .key and .crt, but when I try to run yum against this using ssl:

# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:
[Errno 14] curl#60 - "Peer's certificate issuer has been marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust 
but I'm pretty sure it is done automatically now and I think it was in 
the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have 
this code.


Look at this, 
https://fedoraproject.org/wiki/Features/SharedSystemCertificates


The idea is to add the IPA CA to that and then all tools using SSL 
would "just work".


Something like:

# cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your IPA 
install (and get a new CA):


# rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more recent 
versions of IPA.


rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale ,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden,
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network 
and so

using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we
thought
this might be a good solution.

Is it possible, and, since most online guides defer to "submit 
the CSR

to Verisign" or whomever, how would you go about producing one in
this way?


Not sure I understand the question. The IPA CA is also 
self-signed. For

enrolled systems though at least the CA is pre-distributed so maybe
that
will help.

rob




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













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

Re: [Freeipa-users] a bit off topic- samba + sssd => AD

[lejeczek]

On 03/06/16 15:22, Alexander Bokovoy wrote:

On Fri, 03 Jun 2016, lejeczek wrote:

hi users,

I have a samba and sssd trying AD, it's 7.2 Linux.

That linux box is via sssd and samba talking to AD DC and 
win10 clients get to samba shares, getent pass sees AD 
users, samba can get to DC's shares and win10's clients 
shares, all good except...


smbclient @samba, in other words - to itself - fails

session setup failed: NT_STATUS_LOGON_FAILURE
Do you run winbindd? samba in RHEL 7.2 as of now has a 
regression that
if you don't run winbindd, current code forbids 
establishing anonymous
secure channel connections to AD DCs as part of Badlock 
fixes. The
regression is fixed upstream and RHEL 7.2 packages are 
currently being

tested by Red Hat QE team.

If you start winbindd, this should not affect you -- if 
the machine is
enrolled into Active Directory domain. However, the 
Kerberos error below

makes me thinking you have some problems on AD side as well.

no winbind, I hope to completely relay on sssd.
I should mentioned that I'm fiddling with my sssd so it 
engages two providers, AD and IPA - and it seems to work, 
like a I tried to describe, only that samba smbclient to 
itself is not working.

thanks!




and with smbclient -k

gss_init_sec_context failed with [Unspecified GSS 
failure. Minor code may provide more information: Server 
cifs/swir.private@private.dom not found in Kerberos 
database]
The statement above says your KDC for PRIVATE.DOM does not 
know anything
about cifs/swir.private.dom principal. Fix that problem 
and Kerberos

authentication will be working.



SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: 
NT_STATUS_INTERNAL_ERROR
Failed to setup SPNEGO negTokenInit request: 
NT_STATUS_INTERNAL_ERROR

session setup failed: NT_STATUS_INTERNAL_ERROR

here is a snippet from smb.conf which I thought has 
relevance, I set it up following samba sssd wiki.


  security = ads
 realm = CCNR.DOM
 workgroup = CCNR

 kerberos method = secrets and keytab
 dedicated keytab file = /etc/krb5.swir.ccnr.keytab
 client signing = auto
 client use spnego = yes
 encrypt passwords = yes
 password server = ccnr-winsrv1.ccnr.dom
 netbios name = SWIR

 template shell = /bin/bash
 template homedir = /home/%D/%U

 preferred master = no
 dns proxy = no
 wins server = ccnr-winsrv1.ccnr.dom
 wins proxy = no

 inherit acls = Yes
 map acl inherit = Yes
 acl group control = yes


and in samba log:

 domain_client_validate: Domain password server not 
available.


I've tried samba user list, dead silence.

many thanks,

L.

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




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

Re: [Freeipa-users] Unable to access to web ui

[Rob Crittenden]

seli irithyl wrote:

Yes, you're right, I was also surprised by the subject of the error.
I made changes in the /etc/httpd/conf.d/nss.conf file.
I changed
Listen 443 to Listen 8443
and
 to 
as it was in the /etc/httpd/conf.d/nss.conf file before the update.


You have to change it back. mod_nss must listen on 443.

rob



On Fri, Jun 3, 2016 at 3:30 PM, Rob Crittenden > wrote:

seli irithyl wrote:

# getcert list
returns 9 request ID. All 9 are in status "MONITORING" and
expire after
2017.
So no expired certificate.

Number of certificates and requests being tracked: 9.

[snip]

Request ID '20150313092456':
  status: MONITORING
  stuck: no
  key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
  certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
  CA: IPA
  issuer: CN=Certificate Authority,O=BIOINF.LOCAL
  subject: CN=lead.bioinf.local,O=BIOINF.LOCAL
  expires: 2017-03-13 09:24:56 UTC
  key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
  eku: id-kp-serverAuth,id-kp-clientAuth
  pre-save command:
  post-save command: /usr/lib64/ipa/certmonger/restart_httpd
  track: yes
  auto-renew: yes


[ more snip ]

 > Unfortunately when trying to run any ipa command:
 > [root@lead ~]# ipa service-find lead.bioinf.local
 > ipa: ERROR: cert validation failed for
 >

"E=root@lead.bioinf.local,CN=lead.bioinf.local,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--"
 > ((SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.)
 > ipa: ERROR: cannot connect to
'https://lead.bioinf.local/ipa/json':
 > (SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.


Note that the subject of the certmonger-tracked certificate is
different from the subject reported in the error. This looks like a
default mod_ssl-generated certificate to me. Did you tweak your
Apache config?

rob




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

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Rob Crittenden]

Bret Wortman wrote:

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
see how we go.

Rob, would you have just used the existing "localhost.key" instead of
generating a new one?


No, I think you did the right thing, the default keysize was probably 
still 1024 in F21. I double-checked the getcert-request man page and it 
looks like it will use an existing key if one exists in the key file 
passed in so I was wrong about that bit. You just didn't need to use req 
to generate a CSR as certmonger will do that for you.


rob




On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually
going on here. You generate a CSR and call it a certificate. It is
probably the case that certmonger is ignoring it altogether and
generating its own CSR.


ipa-getcert list shows it approved. I set up SSL in apache to use the
above .key and .crt, but when I try to run yum against this using ssl:

# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:

[Errno 14] curl#60 - "Peer's certificate issuer has been marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust
but I'm pretty sure it is done automatically now and I think it was in
the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
this code.

Look at this,
https://fedoraproject.org/wiki/Features/SharedSystemCertificates

The idea is to add the IPA CA to that and then all tools using SSL
would "just work".

Something like:

# cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your IPA
install (and get a new CA):

# rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more recent
versions of IPA.

rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale ,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden,
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network
and so
using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we
thought
this might be a good solution.

Is it possible, and, since most online guides defer to "submit
the CSR
to Verisign" or whomever, how would you go about producing one in
this way?


Not sure I understand the question. The IPA CA is also
self-signed. For
enrolled systems though at least the CA is pre-distributed so maybe
that
will help.

rob




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















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

Re: [Freeipa-users] a bit off topic- samba + sssd => AD

[lejeczek]

On 03/06/16 15:11, Sumit Bose wrote:

On Fri, Jun 03, 2016 at 02:39:00PM +0100, lejeczek wrote:

hi users,

I have a samba and sssd trying AD, it's 7.2 Linux.

That linux box is via sssd and samba talking to AD DC and win10 clients get
to samba shares, getent pass sees AD users, samba can get to DC's shares and
win10's clients shares, all good except...

smbclient @samba, in other words - to itself - fails

session setup failed: NT_STATUS_LOGON_FAILURE

and with smbclient -k

gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may
provide more information: Server cifs/swir.private@private.dom not found
in Kerberos database]

Which realm is PRIVATE.DOM? What does

 $ klist -k -t /etc/krb5.swir.ccnr.keytab

return?

$ klist -k -t /etc/krb5.swir.ccnr.keytab
Keytab name: FILE:/etc/krb5.swir.ccnr.keytab
KVNO Timestamp Principal
 - 


   4 01/01/70 01:00:00 host/swir.private.ccnr@ccnr.dom
   4 01/01/70 01:00:00 host/swir.private.ccnr@ccnr.dom
   4 01/01/70 01:00:00 host/swir.private.ccnr@ccnr.dom
   4 01/01/70 01:00:00 host/swir.private.ccnr@ccnr.dom
   4 01/01/70 01:00:00 host/swir.private.ccnr@ccnr.dom

and swir runs samba, but I'm trying to sssd together AD & 
IPA, I should have mentioned.
From DNS perspective it's AD = ccnr.dom and IPA = 
private.ccnr.dom, everything seems to resolve OK, both @AD 
and @IPA ends.

And my sssd.conf:

ipa_hostname = swir.private.ccnr.dom
chpass_provider = ipa
ipa_server = swir.private.ccnr.dom
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
#krb5_keytab = /etc/krb5.private.ccnr.keytab

[domain/ccnr.dom]
ad_domain = ccnr.dom
krb5_realm = CCNR.DOM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
auth_provider = ad
krb5_keytab = /etc/krb5.swir.ccnr.keytab

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2

domains = private.ccnr.dom, ccnr.dom

[nss]
memcache_timeout = 600
homedir_substring = /home
--

AD DC (to which shares smbclient @swir can get to) shows:

C:\Users\Administrator.CCNR-WINSRV1>setspn -L swir
Registered ServicePrincipalNames for 
CN=SWIR,OU=private,DC=ccnr,DC=dom:

cifs/swir.private.ccnr@ccnr.dom
host/swir.private.ccnr.dom
host/swir.private.ccnr@ccnr.dom
HOST/SWIR

like I said, getnet and id see both domains
If I
$ kinit m...@ccnr.dom
$ klist
Ticket cache: KEYRING:persistent:0:krb_ccache_xoHU5iW
Default principal: m...@ccnr.dom

Valid starting ExpiresService principal
03/06/16 16:37:06  04/06/16 02:37:06  krbtgt/ccnr@ccnr.dom


$ smbclient -L //$(hostname) -U m...@ccnr.dom -k
gss_init_sec_context failed with [Unspecified GSS failure.  
Minor code may provide more information: Server 
cifs/swir.private.ccnr@private.ccnr.dom not found in 
Kerberos database]
SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: 
NT_STATUS_INTERNAL_ERROR
Failed to setup SPNEGO negTokenInit request: 
NT_STATUS_INTERNAL_ERROR

session setup failed: NT_STATUS_INTERNAL_ERROR

what I see in last one above is - 
cifs/swir.private.ccnr@private.ccnr.dom
I've just realized, for some reason, and maybe a valid one, 
smbclient don't do - cifs/swir.private.ccnr@ccnr.dom 
which is in the keytabs.


but smbclient fails without -k which I understand should 
then use a password and should be sufficient to authenticate.


many thanks Sumit,
L.


bye,
Sumit


SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR
Failed to setup SPNEGO negTokenInit request: NT_STATUS_INTERNAL_ERROR
session setup failed: NT_STATUS_INTERNAL_ERROR

here is a snippet from smb.conf which I thought has relevance, I set it up
following samba sssd wiki.

security = ads
   realm = CCNR.DOM
   workgroup = CCNR

   kerberos method = secrets and keytab
   dedicated keytab file = /etc/krb5.swir.ccnr.keytab
   client signing = auto
   client use spnego = yes
   encrypt passwords = yes
   password server = ccnr-winsrv1.ccnr.dom
   netbios name = SWIR

   template shell = /bin/bash
   template homedir = /home/%D/%U

   preferred master = no
   dns proxy = no
   wins server = ccnr-winsrv1.ccnr.dom
   wins proxy = no

   inherit acls = Yes
   map acl inherit = Yes
   acl group control = yes


and in samba log:

   domain_client_validate: Domain password server not available.

I've tried samba user list, dead silence.

many thanks,

L.

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


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

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Bret Wortman]

On 06/03/2016 11:02 AM, Rob Crittenden wrote:

Bret Wortman wrote:

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
see how we go.

Rob, would you have just used the existing "localhost.key" instead of
generating a new one?


No, I think you did the right thing, the default keysize was probably 
still 1024 in F21. I double-checked the getcert-request man page and 
it looks like it will use an existing key if one exists in the key 
file passed in so I was wrong about that bit. You just didn't need to 
use req to generate a CSR as certmonger will do that for you.



Good to know.

I tried the update-ca-trust on both the yum server and on my workstation 
but nothing changed even after an httpd restart. I did take a peek 
inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and 
didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but 
I confess I'm not sure what should be where at this point).



Bret


rob




On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:
So for our internal yum server, I created a new key and cert 
request (it

had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually
going on here. You generate a CSR and call it a certificate. It is
probably the case that certmonger is ignoring it altogether and
generating its own CSR.


ipa-getcert list shows it approved. I set up SSL in apache to use the
above .key and .crt, but when I try to run yum against this using ssl:

# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml: 



[Errno 14] curl#60 - "Peer's certificate issuer has been marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would 
have

taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust
but I'm pretty sure it is done automatically now and I think it was in
the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
this code.

Look at this,
https://fedoraproject.org/wiki/Features/SharedSystemCertificates

The idea is to add the IPA CA to that and then all tools using SSL
would "just work".

Something like:

# cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your IPA
install (and get a new CA):

# rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more recent
versions of IPA.

rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale ,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden,
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network
and so
using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we
thought
this might be a good solution.

Is it possible, and, since most online guides defer to "submit
the CSR
to Verisign" or whomever, how would you go about producing one in
this way?


Not sure I understand the question. The IPA CA is also
self-signed. For
enrolled systems though at least the CA is 

Re: [Freeipa-users] a bit off topic- samba + sssd => AD

[Alexander Bokovoy]

On Fri, 03 Jun 2016, lejeczek wrote:



On 03/06/16 15:22, Alexander Bokovoy wrote:

On Fri, 03 Jun 2016, lejeczek wrote:

hi users,

I have a samba and sssd trying AD, it's 7.2 Linux.

That linux box is via sssd and samba talking to AD DC and win10 
clients get to samba shares, getent pass sees AD users, samba can 
get to DC's shares and win10's clients shares, all good except...


smbclient @samba, in other words - to itself - fails

session setup failed: NT_STATUS_LOGON_FAILURE
Do you run winbindd? samba in RHEL 7.2 as of now has a regression 
that
if you don't run winbindd, current code forbids establishing 
anonymous

secure channel connections to AD DCs as part of Badlock fixes. The
regression is fixed upstream and RHEL 7.2 packages are currently 
being

tested by Red Hat QE team.

If you start winbindd, this should not affect you -- if the machine 
is
enrolled into Active Directory domain. However, the Kerberos error 
below

makes me thinking you have some problems on AD side as well.

no winbind, I hope to completely relay on sssd.

You cannot -- at least for now. Samba needs translation between SIDs and
POSIX IDs. This translation cannot be done by SSSD alone right now
because there is no separate mechanism to supply that translation into
Samba from the system level.

SSSD can be used as to imitate SID translation interface of winbindd by
providing a libwbclient replacement but this would mean a lot of other
functionality winbindd provides will be missing as SSSD does not
implement it. 


Finally, you can run winbindd in parallel to SSSD. You just need to
ensure they both have the same understanding how to map usernames and
group names to POSIX ID and back. And you don't need to add winbindd to
/etc/nsswitch.conf or PAM configuration.

I should mentioned that I'm fiddling with my sssd so it engages two 
providers, AD and IPA - and it seems to work, like a I tried to 
describe, only that samba smbclient to itself is not working.

thanks!

SMB services with Kerberos require use of cifs/ service
principal. Your keytab only has host/ keys, and your AD
machine account for the  does not have 'cifs/' SPN
defined. The latter is what causes smbclient -k to fail -- AD DC doesn't
know about 'cifs/' and refuses to issue a service ticket even
before smbclient contacts Samba server.


and with smbclient -k

gss_init_sec_context failed with [Unspecified GSS failure. Minor 
code may provide more information: Server 
cifs/swir.private@private.dom not found in Kerberos database]
The statement above says your KDC for PRIVATE.DOM does not know 
anything

about cifs/swir.private.dom principal. Fix that problem and Kerberos
authentication will be working.



SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: 
NT_STATUS_INTERNAL_ERROR
Failed to setup SPNEGO negTokenInit request: 
NT_STATUS_INTERNAL_ERROR

session setup failed: NT_STATUS_INTERNAL_ERROR

here is a snippet from smb.conf which I thought has relevance, I 
set it up following samba sssd wiki.


 security = ads
realm = CCNR.DOM
workgroup = CCNR

kerberos method = secrets and keytab
dedicated keytab file = /etc/krb5.swir.ccnr.keytab
client signing = auto
client use spnego = yes
encrypt passwords = yes
password server = ccnr-winsrv1.ccnr.dom
netbios name = SWIR

template shell = /bin/bash
template homedir = /home/%D/%U

preferred master = no
dns proxy = no
wins server = ccnr-winsrv1.ccnr.dom
wins proxy = no

inherit acls = Yes
map acl inherit = Yes
acl group control = yes


and in samba log:

domain_client_validate: Domain password server not available.

I've tried samba user list, dead silence.

many thanks,

L.

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






--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Rob Crittenden]

Bret Wortman wrote:



On 06/03/2016 11:02 AM, Rob Crittenden wrote:

Bret Wortman wrote:

I'm not sure I'd call what we have "success" just yet. ;-)

You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
see how we go.

Rob, would you have just used the existing "localhost.key" instead of
generating a new one?


No, I think you did the right thing, the default keysize was probably
still 1024 in F21. I double-checked the getcert-request man page and
it looks like it will use an existing key if one exists in the key
file passed in so I was wrong about that bit. You just didn't need to
use req to generate a CSR as certmonger will do that for you.


Good to know.

I tried the update-ca-trust on both the yum server and on my workstation
but nothing changed even after an httpd restart. I did take a peek
inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and
didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but
I confess I'm not sure what should be where at this point).


You'd only need to do this on the machine acting as a client.

I'm pretty sure yum uses /etc/pki/nssdb. Is the IPA CA in there and trusted?

$ certutil -L -d /etc/pki/nssdb

rob




Bret


rob




On 06/03/2016 09:48 AM, Rob Crittenden wrote:

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert
request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually
going on here. You generate a CSR and call it a certificate. It is
probably the case that certmonger is ignoring it altogether and
generating its own CSR.


ipa-getcert list shows it approved. I set up SSL in apache to use the
above .key and .crt, but when I try to run yum against this using ssl:

# yum search ffmpeg
Loaded plugins: langpacks
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:


[Errno 14] curl#60 - "Peer's certificate issuer has been marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would
have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust
but I'm pretty sure it is done automatically now and I think it was in
the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
this code.

Look at this,
https://fedoraproject.org/wiki/Features/SharedSystemCertificates

The idea is to add the IPA CA to that and then all tools using SSL
would "just work".

Something like:

# cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your IPA
install (and get a new CA):

# rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more recent
versions of IPA.

rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale ,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden,
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network
and so
using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we
thought
this might be a good solution.

Is it possible, and, since most online guides defer to "submit
the CSR
to Verisign" 

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[bret . wortman]

I'll check and report back Tuesday.

Bret Wortman
http://wrapbuddies.co/


On Jun 3, 2016, 1:04 PM -0400, Rob Crittenden, wrote:
> Bret Wortman wrote:
> > 
> > 
> > On 06/03/2016 11:02 AM, Rob Crittenden wrote:
> > > Bret Wortman wrote:
> > > > I'm not sure I'd call what we have "success" just yet. ;-)
> > > > 
> > > > You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
> > > > see how we go.
> > > > 
> > > > Rob, would you have just used the existing "localhost.key" instead of
> > > > generating a new one?
> > > 
> > > No, I think you did the right thing, the default keysize was probably
> > > still 1024 in F21. I double-checked the getcert-request man page and
> > > it looks like it will use an existing key if one exists in the key
> > > file passed in so I was wrong about that bit. You just didn't need to
> > > use req to generate a CSR as certmonger will do that for you.
> > > 
> > Good to know.
> > 
> > I tried the update-ca-trust on both the yum server and on my workstation
> > but nothing changed even after an httpd restart. I did take a peek
> > inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and
> > didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but
> > I confess I'm not sure what should be where at this point).
> 
> You'd only need to do this on the machine acting as a client.
> 
> I'm pretty sure yum uses /etc/pki/nssdb. Is the IPA CA in there and trusted?
> 
> $ certutil -L -d /etc/pki/nssdb
> 
> rob
> 
> > 
> > 
> > Bret
> > 
> > > rob
> > > 
> > > > 
> > > > 
> > > > On 06/03/2016 09:48 AM, Rob Crittenden wrote:
> > > > > Bret Wortman wrote:
> > > > > > So for our internal yum server, I created a new key and cert
> > > > > > request (it
> > > > > > had a localhost key and cert but I wanted to start clean):
> > > > > > 
> > > > > > # openssl genrsa 2048>/etc/pki/tls/private/server.key
> > > > > > # openssl req -new -x509 -nodes -sha1 -days 365 -key
> > > > > > /etc/pki/tls/private/server.key>/etc/pki/tls/certs/server.crt
> > > > > > # ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
> > > > > > /etc/pki/tls/private/server.key -r
> > > > > 
> > > > > I try not to argue with success but I'd be curious what is actually
> > > > > going on here. You generate a CSR and call it a certificate. It is
> > > > > probably the case that certmonger is ignoring it altogether and
> > > > > generating its own CSR.
> > > > > 
> > > > > > ipa-getcert list shows it approved. I set up SSL in apache to use 
> > > > > > the
> > > > > > above .key and .crt, but when I try to run yum against this using 
> > > > > > ssl:
> > > > > > 
> > > > > > # yum search ffmpeg
> > > > > > Loaded plugins: langpacks
> > > > > > https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:
> > > > > > 
> > > > > > 
> > > > > > [Errno 14] curl#60 - "Peer's certificate issuer has been marked as
> > > > > > not trusted by the user."
> > > > > > :
> > > > > > 
> > > > > > Is there a step I need to take on the clients so they'll accept this
> > > > > > cert as trusted? I thought having it be signed by the IPA CA would
> > > > > > have
> > > > > > taken care of that.
> > > > > > 
> > > > > > # ls -l /etc/ipa/ca.crt
> > > > > > -rw-r--r-- 1 root root 2546 Apr 28 2014 /etc/ipa/ca.crt
> > > > > > #
> > > > > 
> > > > > Pretty much only IPA tools know to use this file.
> > > > > 
> > > > > My knowledge is a bit stale on adding the IPA CA to the global trust
> > > > > but I'm pretty sure it is done automatically now and I think it was in
> > > > > the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
> > > > > this code.
> > > > > 
> > > > > Look at this,
> > > > > https://fedoraproject.org/wiki/Features/SharedSystemCertificates
> > > > > 
> > > > > The idea is to add the IPA CA to that and then all tools using SSL
> > > > > would "just work".
> > > > > 
> > > > > Something like:
> > > > > 
> > > > > # cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
> > > > > # update-ca-trust
> > > > > 
> > > > > You'd need to remember to manually undo this if you ever redo your IPA
> > > > > install (and get a new CA):
> > > > > 
> > > > > # rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
> > > > > # update-ca-trust
> > > > > 
> > > > > Like I said, I'm pretty sure this is all automatic in some more recent
> > > > > versions of IPA.
> > > > > 
> > > > > rob
> > > > > 
> > > > > > 
> > > > > > ---
> > > > > > Bret
> > > > > > 
> > > > > > On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:
> > > > > > > Cool. I'll give this a go in the morning.
> > > > > > > 
> > > > > > > Bret Wortman
> > > > > > > http://wrapbuddies.co/
> > > > > > > 
> > > > > > > On Jun 2, 2016, 6:24 PM -0400, Fraser 
> > > > > > > Tweedale,
> > > > > > > wrote:
> > > > > > > > On Thu, Jun 02, 2016 at 05:35:01PM -0400,
> > > > > > > > bret.wort...@damascusgrp.com wrote:
> > > > > > > > > Sorry, let me 

Re: [Freeipa-users] how to setup apache reverse https proxy for freeipa web UI

[Jan Pazdziora]

On Thu, Jun 02, 2016 at 03:00:36PM +0200, Karl Forner wrote:
> 
> My problem is:
> I have an ipa.example.com server on the internal network, with
> self-signed certificates.
> I'd like to be able to connect to the UI from the internet, using
> https with other certificates (e.g. let's encrypt certificates).
> 
> So I tried to setup an SNI apache reverse proxy, but I could not make it work.
> I saw this blog
> [https://www.adelton.com/freeipa/freeipa-behind-ssl-proxy] but I can
> not use the same FQDN name for the LAN and the WAN.
> 
> I tried many many things, I could have the login form, but never could
> not connect. What is the correct way of doing this ?

If the hostname of the proxy and the FreeIPA server differ, you will
likely need some additional configuration on the proxy, to make sure
cookies produced by the FreeIPA server are used by the browser for
the subsequent HTTP requests, and also to make the Referer header
match FreeIPA's expectations. Something like

ProxyPassReverseCookieDomain ipa.example.com ipa.public.company.com
RequestHeader edit Referer ^https://ipa\.public\.company\.com/ 
https://ipa.example.com/

Note that you will not be able to use SSO (Kerberos) authentication
for the accesses via the ipa.public.company.com proxy but I assume
that's not needed.

Hope this helps. I will likely do another writeup about this setup.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

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

Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

[Rob Crittenden]

dan.finkelst...@high5games.com wrote:

A further update: when I try to install the CA component, it erroneously
says that the CA is installed:

root@ipa ~]# ipa-ca-install --skip-conncheck --debug


[ snip ]


ipa : DEBUGThe ipa-ca-install command failed, exception:
SystemExit: CA is already installed.

CA is already installed.


Try:

# pkidestroy -i pki-tomcat -s CA


Yet:

[root@ipa ~]# ipa-csreplica-manage list

Directory Manager password:

ipa.example.com: CA not configured


Two different methods are used to determine whether a CA is installed. 
I'll open a ticket to look into that.


rob





*Daniel Alex Finkelstein*| Senior Dev Ops Engineer

_dan.finkelst...@h5g.com _| 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  and Shake
the Sky 

Follow us on: Facebook , Twitter
, YouTube
, Linkedin


//

/This message and any attachments may contain confidential or privileged
information and are only for the use of the intended recipient of this
message. If you are not the intended recipient, please notify the sender
by return email, and delete or destroy this and all copies of this
message and all attachments. Any unauthorized disclosure, use,
distribution, or reproduction of this message or any attachments is
prohibited and may be unlawful./

*From: * on behalf of Daniel
Finkestein 
*Date: *Thursday, June 2, 2016 at 17:42
*To: *"freeipa-users@redhat.com" 
*Subject: *Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of
FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica,
cannot promote to master

Hi Rob,

There's a few logs in there, I'm not sure which is most informative.
Here are some sections from what I think are relevant logs:

/var/log/pki/pki-tomcat/localhost.log:

Jun 01, 2016 12:16:34 PM org.apache.catalina.core.StandardWrapperValve
invoke

SEVERE: Servlet.service() for servlet [Resteasy] in context with path
[/ca] threw exception

org.jboss.resteasy.spi.UnhandledException:
org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find
MessageBodyWriter for response object of type:
com.netscape.certsrv.base.PKIException$Data of media type:
application/x-www-form-urlencoded

 at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:157)

 at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)

 at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)

 at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)

 at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)

 at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)

 at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

 at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)

 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

 at java.lang.reflect.Method.invoke(Method.java:498)

 at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)

 at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)

 at java.security.AccessController.doPrivileged(Native Method)

 at javax.security.auth.Subject.doAsPrivileged(Subject.java:549)

 at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)

 at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)

 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:297)

 at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)

 at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:191)

 at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:187)

 at java.security.AccessController.doPrivileged(Native Method)

 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:186)

 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

 at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)

 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

 at 

Re: [Freeipa-users] IPA's own ptr record - unresolvable ?

[lejeczek]

On 03/06/16 08:06, Petr Spacek wrote:

On 2.6.2016 18:30, lejeczek wrote:

hi users,

I do (all on IPA server)

$ host 10.5.6.100
Host 100.6.5.10.in-addr.arpa. not found: 3(NXDOMAIN)

I do:

$ host 10.5.6.17
17.6.5.10.in-addr.arpa domain name pointer ..

I do:

$ ipa dnsrecord-find 5.10.in-addr.arpa
   Record name: @
   NS record: rider.private.dom., swir.private.dom.,
  work5.private.dom.

   Record name: 19.10
   PTR record: work1.private.dom.

   Record name: 23.10
   PTR record: work5.private.dom.

   Record name: 100.6
   PTR record: rider.private.dom.

   Record name: 17.6
   PTR record: dzien.private.dom.

   Record name: 32.6
   PTR record: swir.private.dom.

Number of entries returned 6


dig also find these records.

this is probably why replica fails with:

ipa.ipapython.install.cli.install_tool(Replica): ERRORUnable to resolve
the IP address 10.5.6.100 to a host name, check /etc/hosts and DNS name
resolution

must be something trivial?

Likely :-) It could have multiple reasons.
E.g. DNS delegation from parent domain could be broken which could cause this 
etc.

Please try commands
$ dig -x  PTR

and

$ dig -x  SOA

and post their output, preferably without redacting it because the attempt to
hind real names often hide the root cause. I will have a look.


hi Petr
I have to redact, but I do it programmaticaly.
I think it happened after addition of second(last) replica, 
I initially installed server with 5.10.in-addr.arpa.

Now I do:

$ ipa dnszone-find
  Zone name: 5.10.in-addr.arpa.
  Active zone: TRUE
  Authoritative nameserver: rider.private.dom.
  Administrator e-mail address: hostmaster.private.dom.
  SOA serial: 1464884896
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

  Zone name: 10.5.10.in-addr.arpa.
  Active zone: TRUE
  Authoritative nameserver: work5.private.dom.
  Administrator e-mail address: hostmaster.private.dom.
  SOA serial: 1464489313
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

  Zone name: 6.5.10.in-addr.arpa.
  Active zone: TRUE
  Authoritative nameserver: swir.private.dom.
  Administrator e-mail address: hostmaster.private.dom.
  SOA serial: 1464880660
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

  Zone name: private.dom.
  Active zone: TRUE
  Authoritative nameserver: rider.private.dom.
  Administrator e-mail address: hostmaster.private.dom.
  SOA serial: 1464884764
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Allow query: any;
  Allow transfer: none;

Number of entries returned 4


and I dag "any" type of record and misread it, there is no 
ptr record returned, I could not get how delegation can be 
involved here.
It's IPA(rider is the first server) own 5.10.in-addr.arpa. 
And rider sees 10.5.6.32 10.5.6.17 etc. but not it's own 
record, which according to:


$ ipa dnsrecord-find 5.10.in-addr.arpa

exists:

  Record name: 100.6
  PTR record: rider.private.dom.

$ dig -x 10.5.6.100 +qr soa
;; QUESTION SECTION:
;100.6.5.10.in-addr.arpa. IN  SOA

;; AUTHORITY SECTION:
6.5.10.in-addr.arpa.  0 IN  SOA rider.private.dom. 
hostmaster.private.dom. 1464880660 3600 900 1209600 3600


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

$ dig -x 10.5.6.100 +qr ptr
;; QUESTION SECTION:
;100.6.5.10.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
6.5.10.in-addr.arpa.  3600  IN  SOA rider.private.dom. 
hostmaster.private.dom. 1464880660 3600 900 1209600 3600


;; Query time: 1 msec

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

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Bret Wortman]

So for our internal yum server, I created a new key and cert request (it 
had a localhost key and cert but I wanted to start clean):


   # openssl genrsa 2048 > /etc/pki/tls/private/server.key
   # openssl req -new -x509 -nodes -sha1 -days 365 -key
   /etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
   # ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
   /etc/pki/tls/private/server.key -r

ipa-getcert list shows it approved. I set up SSL in apache to use the 
above .key and .crt, but when I try to run yum against this using ssl:


   # yum search ffmpeg
   Loaded plugins: langpacks
   
https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:
   [Errno 14] curl#60 - "Peer's certificate issuer has been marked as
   not trusted by the user."
   :

Is there a step I need to take on the clients so they'll accept this 
cert as trusted? I thought having it be signed by the IPA CA would have 
taken care of that.


   # ls -l /etc/ipa/ca.crt
   -rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
   #

---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale , 
wrote:
On Thu, Jun 02, 2016 at 05:35:01PM -0400, 
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden, 
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network and so
using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we 
thought

this might be a good solution.

Is it possible, and, since most online guides defer to "submit the CSR
to Verisign" or whomever, how would you go about producing one in 
this way?


Not sure I understand the question. The IPA CA is also self-signed. For
enrolled systems though at least the CA is pre-distributed so maybe 
that

will help.

rob




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







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

Re: [Freeipa-users] Unable to access to web ui

[Petr Vobornik]

On 06/03/2016 11:11 AM, seli irithyl wrote:
> Sorry Martin,
> I rebooted the IdM server:
> [root@lead sssd]# ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> ipa_memcached Service: RUNNING
> httpd Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa: INFO: The ipactl command was successful
> 
> I checked DNS and it is ok
> 
> I can login from any host.
> 
> Unfortunately when trying to run any ipa command:
> [root@lead ~]# ipa service-find lead.bioinf.local
> ipa: ERROR: cert validation failed for 
> "E=root@lead.bioinf.local,CN=lead.bioinf.local,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--"
>  
> ((SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.)
> ipa: ERROR: cannot connect to 'https://lead.bioinf.local/ipa/json': 
> (SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.
> 
> Is anybody has an idea on where and what to check next ?
> Thx,
> 
> Seli
> 

does
 # getcert list

show any expired certificate?

Do you use IPA with externally signed CA cert? Are they valid?

> 
> 
> On Tue, May 31, 2016 at 8:33 AM, Martin Kosek  > wrote:
> 
> Hello Seli,
> 
> Please reply to mailing list directly so that others can benefit from the
> thread as well.
> 
> Thanks,
> Martin
> 
> On 05/30/2016 06:17 PM, seli irithyl wrote:
>  > Freeipa version : 4.2.0-15.0.1.el7.centos.6.1
>  > FF: 45.1.1
>  > Could this problem be related to mod_ssl and mod_nss for httpd ?
>  > Looking the logs, it seems there are lots of problems, here are some
> parts that
>  > look strange to me (and are probably unrelated) :
>  > 1 sssd:
>  >  1.1 krb5_child.log
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [unpack_buffer]
>  > (0x0100): cmd [249] uid [1713400053] gid [1713400053] validate [true]
> enterprise
>  > principal [false] offline [false] UPN [koto@BIOINF.LOCAL]
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [k5c_setup_fast]
>  > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to
> [host/lead.bioinf.local@BIOINF.LOCAL]
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
>  > [check_fast_ccache] (0x0200): FAST TGT is still valid.
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832 
> [become_user]
>  > (0x0200): Trying to become user [1713400053][1713400053].
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
>  > [set_lifetime_options] (0x0100): SSSD_KRB5_RENEWABLE_LIFETIME is set 
> to [7d]
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
>  > [set_lifetime_options] (0x0100): SSSD_KRB5_LIFETIME is set to [1d]
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
>  > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to 
> [true]
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
>  > [sss_krb5_prompter] (0x0020): Cannot handle password prompts.
>  >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [k5c_send_data]
>  > (0x0200): Received error code 0
>  >  1.2 sssd_bioinf.local.log
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [check_ccache_files] (0x0200): Failed to check ccache file
>  > [KEYRING:persistent:1713400031].
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [check_ccache_files] (0x0200): Failed to check ccache file
>  > [KEYRING:persistent:1713400053].
>  >  ...
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [check_and_export_options] (0x0100): No KDC explicitly configured, 
> using
> defaults.
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [check_and_export_options] (0x0100): No kpasswd server explicitly 
> configured,
>  > using the KDC or defaults.
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty!
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [load_backend_module] (0x0200): no module name found in confdb, using 
> [ipa].
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [common_parse_search_base] (0x0100): Search base added:
>  > [SUDO][ou=SUDOers,dc=bioinf,dc=local][SUBTREE][]
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> [check_ipv4_addr]
>  > (0x0200): Loopback IPv4 address 127.0.0.1
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> [check_ipv6_addr]
>  > (0x0200): Loopback IPv6 address ::1
>  >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
>  > [load_backend_module] (0x0200): no module name found in confdb, using 
> 

Re: [Freeipa-users] Unable to access to web ui

[seli irithyl]

# getcert list
returns 9 request ID. All 9 are in status "MONITORING" and expire after
2017.
So no expired certificate.

Number of certificates and requests being tracked: 9.
Request ID '20150313092422':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-BIOINF-LOCAL',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-BIOINF-LOCAL/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-BIOINF-LOCAL',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=lead.bioinf.local,O=BIOINF.LOCAL
expires: 2017-03-13 09:24:21 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv BIOINF-LOCAL
track: yes
auto-renew: yes
Request ID '20150313092456':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=lead.bioinf.local,O=BIOINF.LOCAL
expires: 2017-03-13 09:24:56 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
Request ID '20150710083112':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
certificate:
type=NSSDB,location='/etc/pki/nssdb',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=lead.bioinf.local,O=BIOINF.LOCAL
expires: 2017-07-10 08:31:16 UTC
principal name: host/lead.bioinf.local@BIOINF.LOCAL
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20160106131740':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=CA Audit,O=BIOINF.LOCAL
expires: 2017-03-02 09:24:01 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20160106131741':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=OCSP Subsystem,O=BIOINF.LOCAL
expires: 2017-03-02 09:24:00 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20160106131742':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=BIOINF.LOCAL
subject: CN=CA Subsystem,O=BIOINF.LOCAL
expires: 2017-03-02 09:24:01 UTC
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"subsystemCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20160106131743':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert

Re: [Freeipa-users] IPA's own ptr record - unresolvable ?

[Petr Spacek]

On 3.6.2016 10:33, lejeczek wrote:
> 
> 
> On 03/06/16 08:06, Petr Spacek wrote:
>> On 2.6.2016 18:30, lejeczek wrote:
>>> hi users,
>>>
>>> I do (all on IPA server)
>>>
>>> $ host 10.5.6.100
>>> Host 100.6.5.10.in-addr.arpa. not found: 3(NXDOMAIN)
>>>
>>> I do:
>>>
>>> $ host 10.5.6.17
>>> 17.6.5.10.in-addr.arpa domain name pointer ..
>>>
>>> I do:
>>>
>>> $ ipa dnsrecord-find 5.10.in-addr.arpa
>>>Record name: @
>>>NS record: rider.private.dom., swir.private.dom.,
>>>   work5.private.dom.
>>>
>>>Record name: 19.10
>>>PTR record: work1.private.dom.
>>>
>>>Record name: 23.10
>>>PTR record: work5.private.dom.
>>>
>>>Record name: 100.6
>>>PTR record: rider.private.dom.
>>>
>>>Record name: 17.6
>>>PTR record: dzien.private.dom.
>>>
>>>Record name: 32.6
>>>PTR record: swir.private.dom.
>>> 
>>> Number of entries returned 6
>>>
>>>
>>> dig also find these records.
>>>
>>> this is probably why replica fails with:
>>>
>>> ipa.ipapython.install.cli.install_tool(Replica): ERRORUnable to resolve
>>> the IP address 10.5.6.100 to a host name, check /etc/hosts and DNS name
>>> resolution
>>>
>>> must be something trivial?
>> Likely :-) It could have multiple reasons.
>> E.g. DNS delegation from parent domain could be broken which could cause
>> this etc.
>>
>> Please try commands
>> $ dig -x  PTR
>>
>> and
>>
>> $ dig -x  SOA
>>
>> and post their output, preferably without redacting it because the attempt to
>> hind real names often hide the root cause. I will have a look.
> I see, later after first server installation IPA (itself) created:
> 6.5.10.in-addr.arpa. and that was where PTR record was missing.
> Is this one of test cases where it brakes? If one uses 5.10.in-addr.arpa class
> for reverse zone? Is this against any standard?

Feel free to delete IPA-created zone 6.5.10.in-addr.arpa. and put PTR record
into your own zone 5.10.in-addr.arpa.

FreeIPA installer is buggy in this aspect. It should be fixed in one of next
releases as part of External DNS integration.

Please be so kind and open a ticket
https://fedorahosted.org/freeipa/newticket
and describe your problem in there so we do not forget to cover this case.

Thank you for your time!

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

[Kay Zhou Y]

Hi Rob,

Actually certmonger service is failed after restart it, but without its active 
the two 389-ds and apache certs could be renewed as well.. it's weird..

root@ecnshlx3039-test2(SH):~ #systemctl status certmonger
certmonger.service - Certificate monitoring and PKI enrollment
  Loaded: loaded (/usr/lib/systemd/system/certmonger.service; disabled)
  Active: failed (Result: exit-code) since Mon, 23 Jun 2014 00:31:11 
+0200; 5s ago
 Process: 2198 ExecStart=/usr/sbin/certmonger -S -p 
/var/run/certmonger.pid -n $OPTS (code=exited, status=1/FAILURE)
  CGroup: name=systemd:/system/certmonger.service

Jun 23 00:31:11 ecnshlx3039-test2.sh.cn.ao.ericsson.se certmonger[2198]: 
2014-06-23 00:31:11 [2198] Unable to set well-known bus name 
"org.fedorahosted.certmonger": (2).
Jun 23 00:31:11 ecnshlx3039-test2.sh.cn.ao.ericsson.se certmonger[2198]: Error 
connecting to D-Bus.

I have already renewed two 389-ds and apache certs  to 20160622, however , 
since there is no enough time for us before expiration. So we try to seek other 
workarounds, and one solution for us is disable expired certificate according 
to 
https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/troubleshooting-servers-and-replicas.html#expired-certs
 
After test, it could work, but IPA command could not be used. But seems we can 
still get data from LDAP. 

If there is any other way we could use to disable such expired certs without 
impact from your side? 

Thanks for your great support again :)

BR//Kay

-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Friday, June 03, 2016 5:34 AM
To: Kay Zhou Y; freeipa-users@redhat.com
Cc: Doris Hongmei; Xionglin Gu
Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue

Kay Zhou Y wrote:
> Hi Rob,
>
> We are using fedora 17.
> And as you said, when I roll back time to when the CA subsystem and ipaCert 
> are valid. Then restart ipatcl,  "pki-cad@pki-ca.service" is active as normal.
> But these five certs could not renewed as before. (actually I always 
> restart ipa world after I roll back time, this 
> "pki-cad@pki-ca.service" should be active but I just ignore it 
> before... )

With the time rolled back what I'd do is restart certmonger then run in a loop 
with a 1 second sleep ipa-getcert list and ensure that the statuses are 
changing to SUBMITTING, etc., and see what the final state is. certmonger logs 
to syslog so that might give some clues what is happening, and you can watch 
the dogtag logs to ensure the requests are being received, etc.

rob

>
> Thanks,
> BR//Kay
>
> -Original Message-
> From: Rob Crittenden [mailto:rcrit...@redhat.com]
> Sent: Wednesday, June 01, 2016 10:37 PM
> To: Kay Zhou Y; freeipa-users@redhat.com
> Cc: Doris Hongmei; Xionglin Gu
> Subject: Re: [Freeipa-users] IPA 2.2 Certificate Renewal issue
>
> Kay Zhou Y wrote:
>> Hi Rob,
>>
>> 1.  I have made snapshots for this system for test, so NSS databases has 
>> been backed up.
>>
>> 2.  For the pki-cad service, I can't find it in my system, it shows there is 
>> no such service.
>> but there is one service failed as below:
>>
>> root@ecnshlx3039-test2(SH):requests #systemctl status 
>> pki-cad@pki-ca.service pki-cad@pki-ca.service - PKI Certificate Authority 
>> Server pki-ca
>> Loaded: loaded (/lib/systemd/system/pki-cad@.service; enabled)
>> Active: failed (Result: exit-code) since Wed, 01 Jun 2016 
>> 06:28:53 +0200; 23min ago
>>Process: 2675 ExecStop=/usr/bin/pkicontrol stop ca %i 
>> (code=exited, status=1/FAILURE)
>>Process: 2525 ExecStart=/usr/bin/pkicontrol start ca %i 
>> (code=exited, status=0/SUCCESS)
>>   Main PID: 2593 (code=exited, status=0/SUCCESS)
>> CGroup: name=systemd:/system/pki-cad@.service/pki-ca
>>
>> Jun 01 06:28:49 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2549]:
>> pam_unix(runuser-l:session): session opened for user pkius...d=0) Jun
>> 01 06:28:49 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2549]:
>> pam_unix(runuser-l:session): session closed for user pkiuser Jun 01
>> 06:28:52 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2694]:
>> pam_unix(runuser-l:session): session opened for user pkius...d=0) Jun
>> 01 06:28:53 ecnshlx3039-test2.sh.cn.ao.ericsson.se runuser[2694]:
>> pam_unix(runuser-l:session): session closed for user pkiuser
>>
>> I can't start it normally, even the log just said:
>> Jun  1 06:54:39 ecnshlx3039-test2 systemd[1]: pki-cad@pki-ca.service:
>> control process exited, code=exited status=1 Jun  1 06:54:39 
>> ecnshlx3039-test2 systemd[1]: Unit pki-cad@pki-ca.service entered failed 
>> state.
>>
>> I will google more to try to start it firstly.
>
> Ok, this is very confusing to me. What distribution are you running? I have 
> the feeling you are running an extremely outdated version of Fedora.
>
> Yes, you need the CA up in order to get the certificates renewed. Look at 
> catalina.out, the log "debug" and the 

Re: [Freeipa-users] Unable to access to web ui

[seli irithyl]

Sorry Martin,
I rebooted the IdM server:
[root@lead sssd]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful

I checked DNS and it is ok

I can login from any host.

Unfortunately when trying to run any ipa command:
[root@lead ~]# ipa service-find lead.bioinf.local
ipa: ERROR: cert validation failed for
"E=root@lead.bioinf.local,CN=lead.bioinf.local,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--"
((SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.)
ipa: ERROR: cannot connect to 'https://lead.bioinf.local/ipa/json':
(SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.

Is anybody has an idea on where and what to check next ?
Thx,

Seli



On Tue, May 31, 2016 at 8:33 AM, Martin Kosek  wrote:

> Hello Seli,
>
> Please reply to mailing list directly so that others can benefit from the
> thread as well.
>
> Thanks,
> Martin
>
> On 05/30/2016 06:17 PM, seli irithyl wrote:
> > Freeipa version : 4.2.0-15.0.1.el7.centos.6.1
> > FF: 45.1.1
> > Could this problem be related to mod_ssl and mod_nss for httpd ?
> > Looking the logs, it seems there are lots of problems, here are some
> parts that
> > look strange to me (and are probably unrelated) :
> > 1 sssd:
> >  1.1 krb5_child.log
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [unpack_buffer]
> > (0x0100): cmd [249] uid [1713400053] gid [1713400053] validate [true]
> enterprise
> > principal [false] offline [false] UPN [koto@BIOINF.LOCAL]
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [k5c_setup_fast]
> > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to
> [host/lead.bioinf.local@BIOINF.LOCAL]
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> > [check_fast_ccache] (0x0200): FAST TGT is still valid.
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [become_user]
> > (0x0200): Trying to become user [1713400053][1713400053].
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> > [set_lifetime_options] (0x0100): SSSD_KRB5_RENEWABLE_LIFETIME is set to
> [7d]
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> > [set_lifetime_options] (0x0100): SSSD_KRB5_LIFETIME is set to [1d]
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to
> [true]
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> > [sss_krb5_prompter] (0x0020): Cannot handle password prompts.
> >  (Mon May 30 17:18:05 2016) [[sssd[krb5_child[32832
> [k5c_send_data]
> > (0x0200): Received error code 0
> >  1.2 sssd_bioinf.local.log
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [check_ccache_files] (0x0200): Failed to check ccache file
> > [KEYRING:persistent:1713400031].
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [check_ccache_files] (0x0200): Failed to check ccache file
> > [KEYRING:persistent:1713400053].
> >  ...
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [check_and_export_options] (0x0100): No KDC explicitly configured, using
> defaults.
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [check_and_export_options] (0x0100): No kpasswd server explicitly
> configured,
> > using the KDC or defaults.
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [parse_krb5_map_user] (0x0200): Warning: krb5_map_user is empty!
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [load_backend_module] (0x0200): no module name found in confdb, using
> [ipa].
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [common_parse_search_base] (0x0100): Search base added:
> > [SUDO][ou=SUDOers,dc=bioinf,dc=local][SUBTREE][]
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> [check_ipv4_addr]
> > (0x0200): Loopback IPv4 address 127.0.0.1
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> [check_ipv6_addr]
> > (0x0200): Loopback IPv6 address ::1
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [load_backend_module] (0x0200): no module name found in confdb, using
> [ipa].
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [common_parse_search_base] (0x0100): Search base added:
> > [AUTOFS][cn=default,cn=automount,dc=bioinf,dc=local][SUBTREE][]
> >  (Mon May 30 17:16:01 2016) [sssd[be[bioinf.local]]]
> > [load_backend_module] (0x0200): no module name found in confdb, using
> [ipa].
> >  ...
> >  (Mon May 30 17:16:11 2016) [sssd[be[bioinf.local]]]
> > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse
> domain SID
> > from [(null)]
> >  (Mon May 30 17:16:11 2016) 

Re: [Freeipa-users] a bit off topic- samba + sssd => AD

[Sumit Bose]

On Fri, Jun 03, 2016 at 02:39:00PM +0100, lejeczek wrote:
> hi users,
> 
> I have a samba and sssd trying AD, it's 7.2 Linux.
> 
> That linux box is via sssd and samba talking to AD DC and win10 clients get
> to samba shares, getent pass sees AD users, samba can get to DC's shares and
> win10's clients shares, all good except...
> 
> smbclient @samba, in other words - to itself - fails
> 
> session setup failed: NT_STATUS_LOGON_FAILURE
> 
> and with smbclient -k
> 
> gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may
> provide more information: Server cifs/swir.private@private.dom not found
> in Kerberos database]

Which realm is PRIVATE.DOM? What does

$ klist -k -t /etc/krb5.swir.ccnr.keytab

return?

bye,
Sumit

> 
> SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR
> Failed to setup SPNEGO negTokenInit request: NT_STATUS_INTERNAL_ERROR
> session setup failed: NT_STATUS_INTERNAL_ERROR
> 
> here is a snippet from smb.conf which I thought has relevance, I set it up
> following samba sssd wiki.
> 
>security = ads
>   realm = CCNR.DOM
>   workgroup = CCNR
> 
>   kerberos method = secrets and keytab
>   dedicated keytab file = /etc/krb5.swir.ccnr.keytab
>   client signing = auto
>   client use spnego = yes
>   encrypt passwords = yes
>   password server = ccnr-winsrv1.ccnr.dom
>   netbios name = SWIR
> 
>   template shell = /bin/bash
>   template homedir = /home/%D/%U
> 
>   preferred master = no
>   dns proxy = no
>   wins server = ccnr-winsrv1.ccnr.dom
>   wins proxy = no
> 
>   inherit acls = Yes
>   map acl inherit = Yes
>   acl group control = yes
> 
> 
> and in samba log:
> 
>   domain_client_validate: Domain password server not available.
> 
> I've tried samba user list, dead silence.
> 
> many thanks,
> 
> L.
> 
> -- 
> 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

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

Re: [Freeipa-users] a bit off topic- samba + sssd => AD

[Alexander Bokovoy]

On Fri, 03 Jun 2016, lejeczek wrote:

hi users,

I have a samba and sssd trying AD, it's 7.2 Linux.

That linux box is via sssd and samba talking to AD DC and win10 
clients get to samba shares, getent pass sees AD users, samba can get 
to DC's shares and win10's clients shares, all good except...


smbclient @samba, in other words - to itself - fails

session setup failed: NT_STATUS_LOGON_FAILURE

Do you run winbindd? samba in RHEL 7.2 as of now has a regression that
if you don't run winbindd, current code forbids establishing anonymous
secure channel connections to AD DCs as part of Badlock fixes. The
regression is fixed upstream and RHEL 7.2 packages are currently being
tested by Red Hat QE team.

If you start winbindd, this should not affect you -- if the machine is
enrolled into Active Directory domain. However, the Kerberos error below
makes me thinking you have some problems on AD side as well.



and with smbclient -k

gss_init_sec_context failed with [Unspecified GSS failure.  Minor code 
may provide more information: Server cifs/swir.private@private.dom 
not found in Kerberos database]

The statement above says your KDC for PRIVATE.DOM does not know anything
about cifs/swir.private.dom principal. Fix that problem and Kerberos
authentication will be working.



SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: 
NT_STATUS_INTERNAL_ERROR

Failed to setup SPNEGO negTokenInit request: NT_STATUS_INTERNAL_ERROR
session setup failed: NT_STATUS_INTERNAL_ERROR

here is a snippet from smb.conf which I thought has relevance, I set 
it up following samba sssd wiki.


  security = ads
 realm = CCNR.DOM
 workgroup = CCNR

 kerberos method = secrets and keytab
 dedicated keytab file = /etc/krb5.swir.ccnr.keytab
 client signing = auto
 client use spnego = yes
 encrypt passwords = yes
 password server = ccnr-winsrv1.ccnr.dom
 netbios name = SWIR

 template shell = /bin/bash
 template homedir = /home/%D/%U

 preferred master = no
 dns proxy = no
 wins server = ccnr-winsrv1.ccnr.dom
 wins proxy = no

 inherit acls = Yes
 map acl inherit = Yes
 acl group control = yes


and in samba log:

 domain_client_validate: Domain password server not available.

I've tried samba user list, dead silence.

many thanks,

L.

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


--
/ Alexander Bokovoy

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

Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Sean Hogan]

Hi Robert..

  Thanks for the reply.  Think I might have found the issue.  The KVM host
my master was running on was showing redhat release 6.5 but the libvrt
packages were showing 6.6.  I think the managers of the kvm host did not
reboot it after an update with new kernel.  Asked them to reboot the KVM
host after I gracefully shut down my NFS profile server and Master IPA
(both run on that host).  However Master IPA would not shutdown so they
rebooted it with the IPA server still running.  Once it was back up and the
2 servers were back up I had to gracefully shutdown the Master IPA and this
time it did shutdown.  Powered back up and it seems to be running fine now.
BTW... there is a lot of info in the upgrade log but will overview it more
later.


Thanks

Sean Hogan







From:   Rob Crittenden 
To: Sean Hogan/Durham/IBM@IBMUS, freeipa-users

Date:   06/02/2016 02:42 PM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem



Sean Hogan wrote:
> Hello All,
>
> Recently went from RHEL 6.7 IPA 3.0.47 to 6.8 IPA 3.0.50. I also think
> (not sure on this yet) that they changed ntp.. ntp used to point at my
> ipas.. but they look like they are now pointing elsewhere. Everything
> was stable at 6.7 3.0.47 pointing to IPA for NTP. However.. they all
> seem to have the same date.
>
>
> My master first IPA is acting up. Replication is off, kerberos seems to
> be off, DNS is off and I think IPA in general on it is toast.
> We do have 8 IPAs.. only FirstMaster is acting up it seems right now and
> all either running on KVM or ESXI.
>
>
> [God@FirstMasterIPA slapd-DOMAIN-LOCAL]# kinit admin
> kinit: Generic error (see e-text) while getting initial credential

ipactl status should show what services are running. It looks like the
KDC is responding but can't talk to the LDAP backend.
>
>
> slapd-DOMAIN-LOCAL
> [01/Jun/2016:18:25:43 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure. Minor code may provide more information (Cannot contact any
> KDC for realm 'DOMAIN.LOCAL')) errno 115 (Operation now in progress)
> [01/Jun/2016:18:25:43 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [01/Jun/2016:18:25:48 -0400] NSMMReplicationPlugin -
> agmt="cn=meToipaserv2.domain.local" (ipaserv2:389): Replication bind
> with GSSAPI auth resumed
> [01/Jun/2016:18:25:48 -0400] NSMMReplicationPlugin -
> agmt="cn=meToipaserv3.domain.local" (ipaserv3:389): Replication bind
> with GSSAPI auth resumed
> [01/Jun/2016:18:25:48 -0400] NSMMReplicationPlugin -
> agmt="cn=meToipaserv4.domain.local" (ipaserv4:389): Replication bind
> with GSSAPI auth resumed
> [01/Jun/2016:18:25:48 -0400] NSMMReplicationPlugin -
> agmt="cn=meToipaserv5.domain.local" (ipaserv5:389): Replication bind
> with GSSAPI auth resumed
> [01/Jun/2016:18:28:04 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI
> Failure: gss_accept_sec_context) errno 0 (Success)
> [01/Jun/2016:18:28:04 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
> [01/Jun/2016:18:28:13 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure. Minor code may provide more information (No credentials
> cache found)) errno 2 (No such file or directory)
> [01/Jun/2016:18:28:13 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [01/Jun/2016:18:33:03 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI
> Failure: gss_accept_sec_context) errno 0 (Success)
> [01/Jun/2016:18:33:03 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
> [01/Jun/2016:18:33:18 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
> GSS failure. Minor code may provide more information (No credentials
> cache found)) errno 2 (No such file or directory)
> [01/Jun/2016:18:33:18 -0400] slapi_ldap_bind - Error: could not perform
> interactive bind for id [] mech [GSSAPI]: error -2 (Local error)
> [01/Jun/2016:18:38:03 -0400] slapd_ldap_sasl_interactive_bind - Error:
> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
> 49 (Invalid 

Re: [Freeipa-users] Unable to access to web ui

[Rob Crittenden]

seli irithyl wrote:

# getcert list
returns 9 request ID. All 9 are in status "MONITORING" and expire after
2017.
So no expired certificate.

Number of certificates and requests being tracked: 9.

[snip]

Request ID '20150313092456':
 status: MONITORING
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=BIOINF.LOCAL
 subject: CN=lead.bioinf.local,O=BIOINF.LOCAL
 expires: 2017-03-13 09:24:56 UTC
 key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command:
 post-save command: /usr/lib64/ipa/certmonger/restart_httpd
 track: yes
 auto-renew: yes


[ more snip ]

> Unfortunately when trying to run any ipa command:
> [root@lead ~]# ipa service-find lead.bioinf.local
> ipa: ERROR: cert validation failed for
> 
"E=root@lead.bioinf.local,CN=lead.bioinf.local,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--"
> ((SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.)
> ipa: ERROR: cannot connect to 'https://lead.bioinf.local/ipa/json':
> (SEC_ERROR_CA_CERT_INVALID) Issuer certificate is invalid.


Note that the subject of the certmonger-tracked certificate is different 
from the subject reported in the error. This looks like a default 
mod_ssl-generated certificate to me. Did you tweak your Apache config?


rob

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

[Freeipa-users] a bit off topic- samba + sssd => AD

[lejeczek]

hi users,

I have a samba and sssd trying AD, it's 7.2 Linux.

That linux box is via sssd and samba talking to AD DC and 
win10 clients get to samba shares, getent pass sees AD 
users, samba can get to DC's shares and win10's clients 
shares, all good except...


smbclient @samba, in other words - to itself - fails

session setup failed: NT_STATUS_LOGON_FAILURE

and with smbclient -k

gss_init_sec_context failed with [Unspecified GSS failure.  
Minor code may provide more information: Server 
cifs/swir.private@private.dom not found in Kerberos 
database]


SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: 
NT_STATUS_INTERNAL_ERROR
Failed to setup SPNEGO negTokenInit request: 
NT_STATUS_INTERNAL_ERROR

session setup failed: NT_STATUS_INTERNAL_ERROR

here is a snippet from smb.conf which I thought has 
relevance, I set it up following samba sssd wiki.


   security = ads
  realm = CCNR.DOM
  workgroup = CCNR

  kerberos method = secrets and keytab
  dedicated keytab file = /etc/krb5.swir.ccnr.keytab
  client signing = auto
  client use spnego = yes
  encrypt passwords = yes
  password server = ccnr-winsrv1.ccnr.dom
  netbios name = SWIR

  template shell = /bin/bash
  template homedir = /home/%D/%U

  preferred master = no
  dns proxy = no
  wins server = ccnr-winsrv1.ccnr.dom
  wins proxy = no

  inherit acls = Yes
  map acl inherit = Yes
  acl group control = yes


and in samba log:

  domain_client_validate: Domain password server not available.

I've tried samba user list, dead silence.

many thanks,

L.

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

Re: [Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

[Rob Crittenden]

Bret Wortman wrote:

So for our internal yum server, I created a new key and cert request (it
had a localhost key and cert but I wanted to start clean):

# openssl genrsa 2048 > /etc/pki/tls/private/server.key
# openssl req -new -x509 -nodes -sha1 -days 365 -key
/etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
# ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
/etc/pki/tls/private/server.key -r


I try not to argue with success but I'd be curious what is actually 
going on here. You generate a CSR and call it a certificate. It is 
probably the case that certmonger is ignoring it altogether and 
generating its own CSR.



ipa-getcert list shows it approved. I set up SSL in apache to use the
above .key and .crt, but when I try to run yum against this using ssl:

# yum search ffmpeg
Loaded plugins: langpacks

https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml:
[Errno 14] curl#60 - "Peer's certificate issuer has been marked as
not trusted by the user."
:

Is there a step I need to take on the clients so they'll accept this
cert as trusted? I thought having it be signed by the IPA CA would have
taken care of that.

# ls -l /etc/ipa/ca.crt
-rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
#


Pretty much only IPA tools know to use this file.

My knowledge is a bit stale on adding the IPA CA to the global trust but 
I'm pretty sure it is done automatically now and I think it was in the 
4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have this code.


Look at this, 
https://fedoraproject.org/wiki/Features/SharedSystemCertificates


The idea is to add the IPA CA to that and then all tools using SSL would 
"just work".


Something like:

# cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

You'd need to remember to manually undo this if you ever redo your IPA 
install (and get a new CA):


# rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
# update-ca-trust

Like I said, I'm pretty sure this is all automatic in some more recent 
versions of IPA.


rob



---
Bret

On 06/02/2016 07:25 PM, bret.wort...@damascusgrp.com wrote:

Cool. I'll give this a go in the morning.

Bret Wortman
http://wrapbuddies.co/

On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale ,
wrote:

On Thu, Jun 02, 2016 at 05:35:01PM -0400,
bret.wort...@damascusgrp.com wrote:

Sorry, let me back up a step. We need to implement hype
everywhere. All our web services. And clients need to get
keys automatically whether through IPA or Puppet. These
systems use IPA for everything but authentication (to keep most
users off). I'm trying to wuss out the easiest way to make this
happen smoothly.


Hi Bret,

You can use the IPA CA to sign service certificates. See
http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.

IPA-enrolled machines already have the IPA certificate in their
trust store. If the clients are IPA-enrolled, everything should
Just Work, otherwise you can distribute the IPA CA certificate to
clients via Puppet** or whatever means you prefer.

** you will have to work out how, because I do not know Puppet :)

Cheers,
Fraser




On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden,
wrote:

Bret Wortman wrote:

Is it possible to use our freeipa CA as a trusted CA to sign our
internal SSL certificates? Our system runs on a private network and so
using the usual trusted sources isn't an option. We've been using
self-signed, but that adds some additional complications and we
thought
this might be a good solution.

Is it possible, and, since most online guides defer to "submit the CSR
to Verisign" or whomever, how would you go about producing one in
this way?


Not sure I understand the question. The IPA CA is also self-signed. For
enrolled systems though at least the CA is pre-distributed so maybe
that
will help.

rob




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











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