[Freeipa-users] FreeIPA certificates to create a keystore

[Hernán Fernández via FreeIPA-users]

Hello,

I have a FreeIPA server and about 7 nodes, each node has a certificate and
a key.

I got those host certificates with:
ipa-getcert request -v -f /etc/security/certificates/host.crt -k
/etc/security/certificates/host.key


I can see the CA certificate it's located at /etc/ipa/ca.crt. Where is the
CAKey file?. I need to create a Keystore for the host.

Thanks

--
Hernán Fernández
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

You can always fetch key tables using kadmin.local on one of the kdc’s.

I haven't actually tried using ipa-getkeytab on the wrong host. I just copied 
the key table. I doubt ipa-getkeytab checks that the hostname matches, but it’s 
always possible.

On Nov 22, 2019, at 3:48 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Oh ok, so I just need to create IPA host and let admin fetch its keytab on all 
real hosts running the service. Fair enough, thanks!

Btw in the meantime I discovered that it is possible to retrieve user's keytab 
with "ipa-getkeytab -r" if you authenticate as "cn=Directory Manager". 
Apparently, it has the rights to do this. But the only way then is by 
specifying its password in command line with "ipa-getkeytab -w" (it doesn't 
support prompting you securely, like kinit or ldapsearch do). So it is NOT a 
good idea to do so, unless you then clean up your history etc Better not :)

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 21:01 Alexander Bokovoy, 
mailto:aboko...@redhat.com>> wrote:
On pe, 22 marras 2019, Charles Hedrick wrote:
>Bound in the sense that it has the hostname as part of the principal,
>not in the sense that there’s any actual connection with that host when
>you use it.
>
>Dmitry Perets wants to use the same principal and key table on several
>hosts. They can simply create a principal for one of them. It and its
>key table can be used anywhere. We do it regularly. I would prefer this
>not to work, but it does.

Correct. And it doesn't need any of the newer functionality too.

>
>On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy 
>mailto:aboko...@redhat.com>>>
> wrote:
>
>No, this is not really what it is. Service principals are always bound
>to a host name but starting with FreeIPA 4.7.0 it is possible to create
>service principals that have no host object with the same host name.
>


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Dmitry Perets via FreeIPA-users]

Oh ok, so I just need to create IPA host and let admin fetch its keytab on
all real hosts running the service. Fair enough, thanks!

Btw in the meantime I discovered that it is possible to retrieve user's
keytab with "ipa-getkeytab -r" if you authenticate as "cn=Directory
Manager". Apparently, it has the rights to do this. But the only way then
is by specifying its password in command line with "ipa-getkeytab -w" (it
doesn't support prompting you securely, like kinit or ldapsearch do). So it
is NOT a good idea to do so, unless you then clean up your history etc
Better not :)

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 21:01 Alexander Bokovoy,  wrote:

> On pe, 22 marras 2019, Charles Hedrick wrote:
> >Bound in the sense that it has the hostname as part of the principal,
> >not in the sense that there’s any actual connection with that host when
> >you use it.
> >
> >Dmitry Perets wants to use the same principal and key table on several
> >hosts. They can simply create a principal for one of them. It and its
> >key table can be used anywhere. We do it regularly. I would prefer this
> >not to work, but it does.
>
> Correct. And it doesn't need any of the newer functionality too.
>
> >
> >On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy  > wrote:
> >
> >No, this is not really what it is. Service principals are always bound
> >to a host name but starting with FreeIPA 4.7.0 it is possible to create
> >service principals that have no host object with the same host name.
> >
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Charles Hedrick wrote:

Bound in the sense that it has the hostname as part of the principal,
not in the sense that there’s any actual connection with that host when
you use it.

Dmitry Perets wants to use the same principal and key table on several
hosts. They can simply create a principal for one of them. It and its
key table can be used anywhere. We do it regularly. I would prefer this
not to work, but it does.


Correct. And it doesn't need any of the newer functionality too.



On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

No, this is not really what it is. Service principals are always bound
to a host name but starting with FreeIPA 4.7.0 it is possible to create
service principals that have no host object with the same host name.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Bound in the sense that it has the hostname as part of the principal, not in 
the sense that there’s any actual connection with that host when you use it.

Dmitry Perets wants to use the same principal and key table on several hosts. 
They can simply create a principal for one of them. It and its key table can be 
used anywhere. We do it regularly. I would prefer this not to work, but it does.

On Nov 22, 2019, at 2:40 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

No, this is not really what it is. Service principals are always bound
to a host name but starting with FreeIPA 4.7.0 it is possible to create
service principals that have no host object with the same host name.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:

In centos 8, the man page for ktuil says 1.16.1. -f isn’t in the man
page nor does it work. yum also shows the version of 1.16.1.

-s is there but not -f. When I tried it without -f the resulting key
table didn’t work.


Because you need to specify salt. To find it out without '-f', you need
to use Kerberos tracing in kinit to see the salt. Below is a script I
made some time ago that automates it but since salt and key can be
anything, it might fail escaping characters too.


#!/bin/bash
if test $# -ne 1 ; then
echo "$0 "
exit 1
fi

user=$1
read -sp "${user}'s pass:" pass
echo
salt=$(printf "%b" "$pass\n" | KRB5_TRACE=/dev/stdout kinit $user|grep salt|cut -d, 
-f2|head -1|cut -d\" -f2-)
KVNO=$(kvno "$user" | awk '{print $NF}')
ETYPE=$(klist -ef | grep -A 1 krbtgt | tail -1 | awk '{print $NF}')
printf "%b" "addent -password -p $user -k $KVNO -e $ETYPE -s 
\"$salt\n$pass\nwrite_kt $user.keytab" | ktutil
printf "%b" "read_kt $user.keytab\nlist\nquit\n" | ktutil
kinit -k -t $user.keytab $user


I think it was published in this mailing list already at least once.



Ubuntu 20.4 will be out shortly. Hopefully Centos 8.x will include 17. But for 
the moment this isn’t a realistic solution.

On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:

service principals have never been bound to hosts. The hostname is just
part of the principal name. It’s not enforced. Pick whatever hostname
you want. (I actually think this is a bug.)


No, this is not really what it is. Service principals are always bound
to a host name but starting with FreeIPA 4.7.0 it is possible to create
service principals that have no host object with the same host name.

So, before FreeIPA 4.7, you needed to do

ipa host-add foo.bar.z
ipa service-add HTTP/foo.bar.z

Since FreeIPA 4.7.0 you can do

ipa service-add HTTP/foo.bar.z --skip-host-check

to create a service principal without managed host. It still would
require foo.bar.z properly mappable to the IPA realm (see
https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/)
but that host doesn't need to exist in IPA.



On Nov 22, 2019, at 2:14 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Hi,

Can you please remind me from which IPA version you support service principals 
not bound to hosts? I think that would be then a better solution for my case, 
as I am really using this user for non-interactive workloads.

And in the meantime, what is the nicest solution for some service that has 
instances on multiple hosts? I could of course define separate service 
principals for each one of them (e.g.. MYSVC/hostname), but if - for example - 
they need to read secrets from the same shared Vault, I then must add all of 
them as its members. And there are 30 instances... That is why I thought to let 
them authenticate with the same principal.

Any solution for this in current version of IPA (4.6)?

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, 
mailto:aboko...@redhat.com>> wrote:
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:

Interesting idea, but seems to require a time machine. The kerberos in
centos 8 is 1.16. I believe Ubuntu 18 is also.


Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.


On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>>>
wrote:

ktutil> add_entry -password -p principal -k kvno -f

The key part here is '-f' which fetches a salt from KDC. Otherwise,
you'd need to use '-s salt' option to specify a salt manually. Option
'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland





--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

service principals have never been bound to hosts. The hostname is just part of 
the principal name. It’s not enforced. Pick whatever hostname you want. (I 
actually think this is a bug.)

On Nov 22, 2019, at 2:14 PM, Dmitry Perets 
mailto:dmitry.per...@gmail.com>> wrote:

Hi,

Can you please remind me from which IPA version you support service principals 
not bound to hosts? I think that would be then a better solution for my case, 
as I am really using this user for non-interactive workloads.

And in the meantime, what is the nicest solution for some service that has 
instances on multiple hosts? I could of course define separate service 
principals for each one of them (e.g.. MYSVC/hostname), but if - for example - 
they need to read secrets from the same shared Vault, I then must add all of 
them as its members. And there are 30 instances... That is why I thought to let 
them authenticate with the same principal.

Any solution for this in current version of IPA (4.6)?

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy, 
mailto:aboko...@redhat.com>> wrote:
On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
>Interesting idea, but seems to require a time machine. The kerberos in
>centos 8 is 1.16. I believe Ubuntu 18 is also.

Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.

>On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
>mailto:freeipa-users@lists.fedorahosted.org>>>
>wrote:
>
>ktutil> add_entry -password -p principal -k kvno -f
>
>The key part here is '-f' which fetches a salt from KDC. Otherwise,
>you'd need to use '-s salt' option to specify a salt manually. Option
>'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
>


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Incidentally, I’m not entirely sure we want this to work. We’re concerned about 
what happens if a system is compromised. That’s a concern because many of our 
systems are run by grad students. With root you could get a copy of someone 
else’s key table. At that point you could use it on any machine in the system, 
and the real user would probably never know.

We use a daemon that allows a user to register that they want to be able to do 
cron jobs (could be used for other things) on that system. The client can fetch 
a credential, which is locked to the IP address and not forward able. (The 
primary intent is to use it with NFS. It doesn’t need forward able 
credentials.) 

> On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy  wrote:
> 
> On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
>> Interesting idea, but seems to require a time machine. The kerberos in
>> centos 8 is 1.16. I believe Ubuntu 18 is also.
> 
> Actually, I did check of the source code commits in upstream MIT
> Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
> '-s' is in 1.16 release. So, it should be in RHEL 8.
> 
>> On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
>> mailto:freeipa-users@lists.fedorahosted.org>>
>> wrote:
>> 
>> ktutil> add_entry -password -p principal -k kvno -f
>> 
>> The key part here is '-f' which fetches a salt from KDC. Otherwise,
>> you'd need to use '-s salt' option to specify a salt manually. Option
>> '-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
>> 
> 
> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Dmitry Perets via FreeIPA-users]

Hi,

Can you please remind me from which IPA version you support service
principals not bound to hosts? I think that would be then a better solution
for my case, as I am really using this user for non-interactive workloads.

And in the meantime, what is the nicest solution for some service that has
instances on multiple hosts? I could of course define separate service
principals for each one of them (e.g.. MYSVC/hostname), but if - for
example - they need to read secrets from the same shared Vault, I then must
add all of them as its members. And there are 30 instances... That is why I
thought to let them authenticate with the same principal.

Any solution for this in current version of IPA (4.6)?

---
Regards,
Dmitry Perets

On Fri, 22 Nov 2019, 20:05 Alexander Bokovoy,  wrote:

> On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:
> >Interesting idea, but seems to require a time machine. The kerberos in
> >centos 8 is 1.16. I believe Ubuntu 18 is also.
>
> Actually, I did check of the source code commits in upstream MIT
> Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
> '-s' is in 1.16 release. So, it should be in RHEL 8.
>
> >On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
> > freeipa-users@lists.fedorahosted.org>>
> >wrote:
> >
> >ktutil> add_entry -password -p principal -k kvno -f
> >
> >The key part here is '-f' which fetches a salt from KDC. Otherwise,
> >you'd need to use '-s salt' option to specify a salt manually. Option
> >'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.
> >
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

In centos 8, the man page for ktuil says 1.16.1. -f isn’t in the man page nor 
does it work. yum also shows the version of 1.16.1.

-s is there but not -f. When I tried it without -f the resulting key table 
didn’t work.

Ubuntu 20.4 will be out shortly. Hopefully Centos 8.x will include 17. But for 
the moment this isn’t a realistic solution.

On Nov 22, 2019, at 2:04 PM, Alexander Bokovoy 
mailto:aboko...@redhat.com>> wrote:

Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Charles Hedrick via FreeIPA-users wrote:

Interesting idea, but seems to require a time machine. The kerberos in
centos 8 is 1.16. I believe Ubuntu 18 is also.


Actually, I did check of the source code commits in upstream MIT
Kerberos and I attributed it wrongly. '-f' is part of 1.17 release and
'-s' is in 1.16 release. So, it should be in RHEL 8.


On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>>
wrote:

ktutil> add_entry -password -p principal -k kvno -f

The key part here is '-f' which fetches a salt from KDC. Otherwise,
you'd need to use '-s salt' option to specify a salt manually. Option
'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Charles Hedrick via FreeIPA-users]

Interesting idea, but seems to require a time machine. The kerberos in centos 8 
is 1.16. I believe Ubuntu 18 is also.

On Nov 22, 2019, at 1:21 PM, Alexander Bokovoy via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:

ktutil> add_entry -password -p principal -k kvno -f

The key part here is '-f' which fetches a salt from KDC. Otherwise,
you'd need to use '-s salt' option to specify a salt manually. Option
'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-getkeytab -r for user keytabs

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Dmitry Perets via FreeIPA-users wrote:

Hi,

Is it possible to retrieve an existing user keytab, without resetting the key?
I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least 
not for user principals:

$ kinit admin

$ ipa-getkeytab -p auto -r -k new.auto.keytab
Failed to load translations
Failed to parse result: Insufficient access rights
Failed to get keytab

Should I add some permissions to the user "admin"...?


It is not possible to use ipa-getkeytab for retrieving a key of a user
in normal environment. There are few reasons for that.

First, ipa-getkeytab relies on access controls that define who can
regenerate a key or retrieve one. These access controls need to be
defined in the target LDAP object (user, in this case). For services and
hosts we have these covered with special commands in IPA CLI:

 ipa {host|service}-{allow|disallow}-{create|retrieve}-keytab

These commands create or remove appropriate attributes from the object
in question. There is no such command for user object. Technically, one
could certainly add the attributes to a user but this wasn't done in
past.

If you know a password, you can generate keytab manually by using ktutil
command:

ktutil> add_entry -password -p principal -k kvno -f

The key part here is '-f' which fetches a salt from KDC. Otherwise,
you'd need to use '-s salt' option to specify a salt manually. Option
'-f' appeared in MIT 1.18, '-s' in MIT Kerberos 1.17.

In past we didn't like the idea to add support for keytab
retrieval/creation to user objects as it would violate the concept that
only user itself knows own password and everyone else is tampering it,
thus causing a password expiration immediately.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: OpenSSH CA with FreeIPA dogtag

[Vinícius Ferrão via FreeIPA-users]

> On 22 Nov 2019, at 15:07, Alexander Bokovoy  wrote:
> 
> On pe, 22 marras 2019, Vinícius Ferrão via FreeIPA-users wrote:
>> Hello,
>> 
>> I would like to know if someone was able to use OpenSSH with
>> certificates managed from the Dogtag CA of FreeIPA.
>> 
>> My goal is to be able to issue certificates for users and perhaps using
>> host keys generated from this CA. I know this may be redundant since
>> FreeIPA already manage host keys, but since the CA is already in-place,
>> why not?
>> 
>> My question is just to know if someone made this, or if someone already
>> tried this and it was broken or unsupported.
>> 
>> Thanks all.
>> 
>> PS: If someone want to just say: leave that, it’s useless. I’m open to
>> hear about it.
> 
> Not to disappoint but use of 'CA certificates' by OpenSSH for naming OpenSSH 
> keys is
> one of sources of confusion. I found 
> https://blog.habets.se/2011/07/OpenSSH-certificates.html
> useful when understanding what it is.
> 
> In short, they aren't anything close to x.509 formats and cannot be
> issued or signed by Dogtag (or any other normal CA).

Thanks Alexander. I will throw the idea on the bin.

> 
> -- 
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: OpenSSH CA with FreeIPA dogtag

[Alexander Bokovoy via FreeIPA-users]

On pe, 22 marras 2019, Vinícius Ferrão via FreeIPA-users wrote:

Hello,

I would like to know if someone was able to use OpenSSH with
certificates managed from the Dogtag CA of FreeIPA.

My goal is to be able to issue certificates for users and perhaps using
host keys generated from this CA. I know this may be redundant since
FreeIPA already manage host keys, but since the CA is already in-place,
why not?

My question is just to know if someone made this, or if someone already
tried this and it was broken or unsupported.

Thanks all.

PS: If someone want to just say: leave that, it’s useless. I’m open to
hear about it.


Not to disappoint but use of 'CA certificates' by OpenSSH for naming OpenSSH 
keys is
one of sources of confusion. I found 
https://blog.habets.se/2011/07/OpenSSH-certificates.html
useful when understanding what it is.

In short, they aren't anything close to x.509 formats and cannot be
issued or signed by Dogtag (or any other normal CA).

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] ipa-getkeytab -r for user keytabs

[Dmitry Perets via FreeIPA-users]

Hi,

Is it possible to retrieve an existing user keytab, without resetting the key? 
I see there is "ipa-getkeytab -r", but it doesn't seem to work for me, at least 
not for user principals:

$ kinit admin

$ ipa-getkeytab -p auto -r -k new.auto.keytab
Failed to load translations
Failed to parse result: Insufficient access rights
Failed to get keytab

Should I add some permissions to the user "admin"...? 

---
Regards,
Dmitry Perets
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] OpenSSH CA with FreeIPA dogtag

[Vinícius Ferrão via FreeIPA-users]

Hello,

I would like to know if someone was able to use OpenSSH with certificates 
managed from the Dogtag CA of FreeIPA.

My goal is to be able to issue certificates for users and perhaps using host 
keys generated from this CA. I know this may be redundant since FreeIPA already 
manage host keys, but since the CA is already in-place, why not?

My question is just to know if someone made this, or if someone already tried 
this and it was broken or unsupported.

Thanks all.

PS: If someone want to just say: leave that, it’s useless. I’m open to hear 
about it.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: ipa-client slows down connections within the container

[Rob Crittenden via FreeIPA-users]

Dmitry Perets via FreeIPA-users wrote:
> Hi,
> 
> Really weird issue... 
> 
> We build a docker container to run some ansible playbooks within it. 
> We notice, that IF the container has "ipa-client" package installed, there is 
> a HUGE performance degradation to execute the same playbook. 
> E.g. 20 seconds without ipa-client vs 2 minutes with ipa-client (6 times 
> worse!).
> 
> Note that:
> - We DO NOT enroll the container. We don't run "ipa-client-install" at any 
> point. We just have the "ipa-client" package INSTALLED (like "yum install 
> ipa-client")
> - The playbooks DO NOT talk to IPA in any way, neither do they run IPA 
> commands. They are totally unrelated to ipa-client actually.
> 
> The delay seems to be during the connection - i.e. it doesn't matter WHAT 
> exactly ansible task does. It gets stuck for all tasks on something like this 
> (note timestamp):
> 
> <192.168.1.1> EXEC /bin/sh -c '/usr/bin/python 
> /root/.ansible/tmp/ansible-tmp-1574346920.3942568-62901531545767/AnsiballZ_stat.py
>  && sleep 0'
>852 1574346920.65004: opening command with Popen()
>852 1574346920.65758: done running command with Popen()
>852 1574346920.65791: getting output with communicate()
>852 1574346921.00213: done communicating   << 
> note the delay here, this happens for each task
>852 1574346921.00227: done with local.exec_command()
> 
> So, JUST HAVING ipa-client installed somehow causes this slowness. 
> 
> Any idea what ipa-client package can alter in system behavior, if we don't 
> actually enroll in IPA domain?
> 
> P.S. You might be wondering WHY we actually have this ipa-client there... 
> well, that's the point: it's totally unrelated to this particular thing... 
> it's just that some of the playbooks need to use IPA commands, that's why we 
> have ipa-client installed. But even NOT the playbook that we are testing 
> above...

The package itself is just files, zero configuration except a bash
completion script. There is a post-install script that should only fire
on upgrades and even then only if the client is configured.

I'd see what else is pulled in my installing ipa-client.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certificate Renewal less than 28days

[Christof Schulze via FreeIPA-users]

The journal shows this on idm1 the CA renewal master (the same on the 
replicas only different time)


Nov  3 07:37:47 idm1 certmonger: Certificate named "subsystemCert 
cert-pki-ca" in token "NSS Certificate DB" in database 
"/etc/pki/pki-tomcat/alias" will not be valid after 2019113038.
Nov  3 07:37:47 idm1 certmonger: Certificate named "auditSigningCert 
cert-pki-ca" in token "NSS Certificate DB" in database 
"/etc/pki/pki-tomcat/alias" will not be valid after 2019113002.
Nov  3 07:37:47 idm1 certmonger: Certificate named "ocspSigningCert 
cert-pki-ca" in token "NSS Certificate DB" in database 
"/etc/pki/pki-tomcat/alias" will not be valid after 20191130111226.
Nov  3 07:37:47 idm1 certmonger: Certificate in file 
"/var/lib/ipa/ra-agent.pem" will not be valid after 20191130111054.


Restarting certmonger did not help.

Resubmitting the certificates on idm1 (renewal master) did renew the 
certificates there.


But they are not renewed on the replica masters (certmonger restarted, 
nothing in the journal). Is there a way to get more output from certmonger?



Is it ok to resubmit them on the replicas too?



On 22.11.19 14:51, Rob Crittenden via FreeIPA-users wrote:

Christof Schulze via FreeIPA-users wrote:

Reading a lot I learned that certificates should be renewed
automatically 28 before expiring.

But some of Certificates are now on less than 10 days.
This is on the CA renewal master:


Request ID '20181008075404':
 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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 subject: CN=OCSP
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 expires: 2019-11-30 11:12:26 UTC
 eku: id-kp-OCSPSigning
 pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
 post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
 track: yes
 auto-renew: yes
Request ID '20181008075405':
 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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 subject: CN=CA
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 expires: 2019-11-30 11:11:38 UTC
 key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
 post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"subsystemCert cert-pki-ca"
 track: yes
 auto-renew: yes

Request ID '20181008075407':
 status: MONITORING
 stuck: no
 key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
 certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
 CA: dogtag-ipa-ca-renew-agent
 issuer: CN=Certificate
Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 subject: CN=IPA
RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
 expires: 2019-11-30 11:10:54 UTC
 key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth,id-kp-clientAuth
 pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
 post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
 track: yes
 auto-renew: yes

Is there a way to get them renewed manually?


I'd start by checking the journal for messages from certmonger. It
should have tried to renew them at least twice now. The other
certificates were able to renew successfullyu?

You can force certmonger to try renewal with:

# getcert resubmit -i 

Or you can just restart certmonger and it'll re-evaluate things.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 

[Freeipa-users] ipa-client slows down connections within the container

[Dmitry Perets via FreeIPA-users]

Hi,

Really weird issue... 

We build a docker container to run some ansible playbooks within it. 
We notice, that IF the container has "ipa-client" package installed, there is a 
HUGE performance degradation to execute the same playbook. 
E.g. 20 seconds without ipa-client vs 2 minutes with ipa-client (6 times 
worse!).

Note that:
- We DO NOT enroll the container. We don't run "ipa-client-install" at any 
point. We just have the "ipa-client" package INSTALLED (like "yum install 
ipa-client")
- The playbooks DO NOT talk to IPA in any way, neither do they run IPA 
commands. They are totally unrelated to ipa-client actually.

The delay seems to be during the connection - i.e. it doesn't matter WHAT 
exactly ansible task does. It gets stuck for all tasks on something like this 
(note timestamp):

<192.168.1.1> EXEC /bin/sh -c '/usr/bin/python 
/root/.ansible/tmp/ansible-tmp-1574346920.3942568-62901531545767/AnsiballZ_stat.py
 && sleep 0'
   852 1574346920.65004: opening command with Popen()
   852 1574346920.65758: done running command with Popen()
   852 1574346920.65791: getting output with communicate()
   852 1574346921.00213: done communicating   << 
note the delay here, this happens for each task
   852 1574346921.00227: done with local.exec_command()

So, JUST HAVING ipa-client installed somehow causes this slowness. 

Any idea what ipa-client package can alter in system behavior, if we don't 
actually enroll in IPA domain?

P.S. You might be wondering WHY we actually have this ipa-client there... well, 
that's the point: it's totally unrelated to this particular thing... it's just 
that some of the playbooks need to use IPA commands, that's why we have 
ipa-client installed. But even NOT the playbook that we are testing above...

---
Regards,
Dmitry Perets
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certificate Renewal less than 28days

[Rob Crittenden via FreeIPA-users]

Christof Schulze via FreeIPA-users wrote:
> Reading a lot I learned that certificates should be renewed
> automatically 28 before expiring.
> 
> But some of Certificates are now on less than 10 days.
> This is on the CA renewal master:
> 
> 
> Request ID '20181008075404':
> 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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> subject: CN=OCSP
> Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> expires: 2019-11-30 11:12:26 UTC
> eku: id-kp-OCSPSigning
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "ocspSigningCert cert-pki-ca"
> track: yes
> auto-renew: yes
> Request ID '20181008075405':
> 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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> subject: CN=CA
> Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> expires: 2019-11-30 11:11:38 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> "subsystemCert cert-pki-ca"
> track: yes
> auto-renew: yes
> 
> Request ID '20181008075407':
> status: MONITORING
> stuck: no
> key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
> certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
> CA: dogtag-ipa-ca-renew-agent
> issuer: CN=Certificate
> Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> subject: CN=IPA
> RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
> expires: 2019-11-30 11:10:54 UTC
> key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
> track: yes
> auto-renew: yes
> 
> Is there a way to get them renewed manually?

I'd start by checking the journal for messages from certmonger. It
should have tried to renew them at least twice now. The other
certificates were able to renew successfullyu?

You can force certmonger to try renewal with:

# getcert resubmit -i 

Or you can just restart certmonger and it'll re-evaluate things.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certificates renewal - for certs issued to services like HTTP

[Rob Crittenden via FreeIPA-users]

John Stokes via FreeIPA-users wrote:
> Hi Rob,
> 
> Thank you for taking the time to respond. 
> Using the command you suggested (getcert list) I can see that the system is 
> not monitoring any of my host certificates. The ones it is tracking seem to 
> be certificates needed for it's internal operation. 

What host certificates? Did you request these yourself? How?

> Is the default behaviour that certs issued to services are not automatically 
> renewed? If yes, can I change that?

Certificates requested with certmonger are automatically renewed.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certificate Renewal less than 28days

[Christof Schulze via FreeIPA-users]

And I always forget, its CentOS 7.7 fully updated, Freeipa 4.6.5

After restarting (backup of the VM-images) the replica CA server now show:

Request ID '20181008070909':
status: MONITORING
ca-error: Invalid cookie: u''
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
subject: CN=OCSP 
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
expires: 2019-11-30 11:12:26 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20181008070910':
status: MONITORING
ca-error: Invalid cookie: u''
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
subject: CN=CA 
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
expires: 2019-11-30 11:11:38 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"subsystemCert cert-pki-ca"
track: yes
auto-renew: yes

Request ID '20181008070913':
status: MONITORING
ca-error: Invalid cookie: u''
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate 
Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
subject: CN=IPA 
RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
expires: 2019-11-30 11:10:54 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Certificate Renewal less than 28days

[Christof Schulze via FreeIPA-users]

Reading a lot I learned that certificates should be renewed 
automatically 28 before expiring.


But some of Certificates are now on less than 10 days.
This is on the CA renewal master:


Request ID '20181008075404':
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
	subject: CN=OCSP 
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY

expires: 2019-11-30 11:12:26 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
	post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"ocspSigningCert cert-pki-ca"

track: yes
auto-renew: yes
Request ID '20181008075405':
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=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
	subject: CN=CA 
Subsystem,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY

expires: 2019-11-30 11:11:38 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
	post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert 
"subsystemCert cert-pki-ca"

track: yes
auto-renew: yes

Request ID '20181008075407':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
CA: dogtag-ipa-ca-renew-agent
	issuer: CN=Certificate 
Authority,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY
	subject: CN=IPA 
RA,O=EXAMPLE.COM,OU=Institute,C=DE,E=christof.schu...@fau.de,L=CITY

expires: 2019-11-30 11:10:54 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes

Is there a way to get them renewed manually?


--
Christof Schulze

Email: christof.schu...@fau.de
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org