Re: [Freeipa-users] ipa-server-install --external-cert-file and exporting dogtag certificates

[Richard Harmonson]

On Mon, Aug 1, 2016 at 10:15 AM, Petr Vobornik  wrote:

> On 07/31/2016 07:45 AM, Richard Harmonson wrote:
> > I having challenges resuming ipa-server-install --external-ca. I am
> reasonably
> > confident I am not providing the right certificate and/or format from my
> > off-line root CA using 389 and Dogtag.
> >
> > Does anyone have instructions on how to accomplish the task of exporting
> the
> > correct certificates in the expected format?
> >
> > Thank you.
> >
>
> The IPA procedure with prerequisites is described at
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca
>
> Or are you rather asking for specific PKI instructions?
>
> e.g.
> *
>
> http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request
>
> *
>
> http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
> --
> Petr Vobornik
>

I read the suggested document, previously, but its an excellent shared
reference for this discussion.

I have successfully submitted and approved the csr. Dogtag provides a web
UI which provides a Base 64 encoded certificate or Base 64 encoded
certificate with CA certificate chain in pkcs7 format.

For the servercert2010601.pem (the signed CSR request signing CA
certificate 0x9) referenced in the article, do I  copy and paste
(-BEGIN .. END-) the base 64 (not pkcs7) to a file using *.pem then
submit using one of the two --external-cert-file?

For the cacert.pem (the Root CA signing certificate 0x1) referenced in the
article, do I copy and paste the base 64 with ca in pkcs7 format to a file
using *.pkcs7 (or pem or does it matter?) then submit using the second
--external-cert-file?

Your guidance is much appreciated.
-- 
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] PKI signing certificate question

[Mateusz Małek]

William,

On 02.08.2016 at 00:41, William Muriithi wrote:
>
> > > Which external CA would be more open to signing this kind of 
certificate?

> >
> > I'm afraid that there is not a single external CA that would sign 
request for CA certificate. (...)

>
> Understandable. Did speak with them and realised its not a straight 
forward thing. As I understand, some CA like Symantec may allow sub CA.


They still would not allow you to have control of sub-CA private key, 
probably. After numerous incidents with mis-issued certificates, browser 
vendors want to be rather safe than sorry - and they have "no mercy" 
policy for any incidents (Symantec is forced to report every certificate 
issued to publicly available certificate transparency logservers, CNNIC 
can no longer issue valid certificates), which makes CA owners rather 
cautious. Revoking trust in one's root CA can even result in bankruptcy 
of such company (see DigiNotar case).


> > There is "X.509 Name Constraints" extension for certificates, 
however external CA would have to make this extension as "critical" 
(which would probably cause compatibility issues with some software - 
"critical" means that if some app doesn't know how to handle this 
extension, it has to report error and do not proceed with establishing 
secure connection).

>
> The certificate with CA basic constraint would only have been used on 
freeIPA, not on other servers. I believe freeIPA could handle such a 
certificate.


FreeIPA should be perfectly fine, the problem is with workstations. 
While (almost?) all software is capable of understanding CA basic 
constraint (as it was known and used for ages), limiting CA to single 
domain zone using X.509 Name Constraints can have some side effects 
(apps on user workstation have to validate all certificates up to root 
CA - if it happens that they don't understand name constraints, they 
will choke on IPA CA certificate if such extension is marked "critical"; 
I think that's the case with majority of Apple devices). I'm not aware 
of any CA that issues technically constrained sub-CAs and I think that 
according to latest guidelines, they are required to publicly disclose 
other sub-CAs issued (and such CAs have to undergo full WebTrust audit 
and have CPS just like regular CA).


I'm using name-constrained CA certificate from our internal root CA, 
however, name constraints extension is not marked as critical. Our 
internally-issued certificates are to be seen only by admins, so it's 
just additional precaution (in case some admin would find it funny to 
use certificate issued from internal CA to MitM another admin) rather 
than security measure.


> > As I understand, --external-ca option should be used when you 
already have configured PKI infrastructure in your network (for example 
Active Directory Certificate Services) and spinning another internal CA 
is not a big deal. You've mentioned that there is already an Active 
Directory domain, (...)

> >
> Interesting. Active Directory certificate service would also be using 
self signed certificate, correct?


Correct. AD Certificate Service can generate its own self-signed root CA 
certificate, just like FreeIPA with internal CA does. As far as I know, 
depending on how you initialize AD CS, this certificate would be 
deployed to domain-joined machines automatically or you would have to 
push it through Group Policies.


> Saw another thread today of someone using --external-ca flag. Wish 
someone who has gone through the process could document the process 
including if they are using external CA


Installation with external CA is quite similar to default setup - when 
you indicate that you want to use external CA, installation process has 
two phases. First, ipa-server-install performs some tasks and generates 
CSR request file. Then, you sign it using your other CA (just make sure 
it preserves CA constraint; we were using EasyRSA, which has separate 
command/profile for creating subordinate CAs). Next, you save your 
signed certificate back to your new IPA server and invoke installer once 
again with additional arguments (this command is shown when first stage 
finishes) - and configuration process continues just like without 
external CA.


--
Best regards
Mateusz Małek

Network and Computer Systems Administrator
Intelligent Information Systems Group
Department of Computer Science
AGH University of Science and Technology

--
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] PKI signing certificate question

[William Muriithi]

Mateusz

> >
> > Which external CA would be more open to signing this kind of
certificate?
>
> I'm afraid that there is not a single external CA that would sign request
for CA certificate. They need to make sure that certificate would not be
used for fraudulent purposes (for e.g. Man-in-the-Middle attacks) which
usually means that they keep control of all subordinate CAs they create
(you can only place requests for client or server certificates - but domain
ownership validation and certificate issuance takes place in their
infrastructure) or they verified that you securely store your private key
in dedicated HSM and have adequate policies and rules regarding certificate
issuance.

Understandable. Did speak with them and realised its not a straight forward
thing. As I understand, some CA like Symantec may allow sub CA.
>
> There is "X.509 Name Constraints" extension for certificates, however
external CA would have to make this extension as "critical" (which would
probably cause compatibility issues with some software - "critical" means
that if some app doesn't know how to handle this extension, it has to
report error and do not proceed with establishing secure connection).

The certificate with CA basic constraint would only have been used on
freeIPA, not on other servers. I believe freeIPA could handle such a
certificate.

> As I understand, --external-ca option should be used when you already
have configured PKI infrastructure in your network (for example Active
Directory Certificate Services) and spinning another internal CA is not a
big deal. You've mentioned that there is already an Active Directory
domain, so the last options seems the easiest one - internal CA root
certificate can be deployed to Windows workstation using AD and IPA
configured with external CA would automatically deploy internal root CA to
Linux workstations on during ipa-client-install.
>
Interesting. Active Directory certificate service would also be using self
signed certificate, correct?

Saw another thread today of someone using --external-ca flag. Wish someone
who has gone through the process could document the process including if
they are using external CA
> --
> Best regards
> Mateusz Małek
Appreciate your feedback a lot.

William
-- 
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] PKI signing certificate question

[Mateusz Małek]

William,

On 29.07.2016 at 22:27, William Muriithi wrote:

> Is anyone here been successful in getting external CA to sign this 
kind of certificate?  I have just tried to convince DigiCert for 2 days 
that there is no harm issuing this kind of certificate as long us it's 
restricted to one domain without success.

>
> Which external CA would be more open to signing this kind of certificate?

I'm afraid that there is not a single external CA that would sign 
request for CA certificate. They need to make sure that certificate 
would not be used for fraudulent purposes (for e.g. Man-in-the-Middle 
attacks) which usually means that they keep control of all subordinate 
CAs they create (you can only place requests for client or server 
certificates - but domain ownership validation and certificate issuance 
takes place in their infrastructure) or they verified that you securely 
store your private key in dedicated HSM and have adequate policies and 
rules regarding certificate issuance.


There is "X.509 Name Constraints" extension for certificates, however 
external CA would have to make this extension as "critical" (which would 
probably cause compatibility issues with some software - "critical" 
means that if some app doesn't know how to handle this extension, it has 
to report error and do not proceed with establishing secure connection). 
Also, if they decide to sell such CA certificate, it would probably be 
much more expensive than "simple" one (as this would allow you to issue 
further certificates for your domain without paying external CAs for them).


You can either go CA-less and buy certificates for all your services or 
use free certificates from Let's Encrypt (if you want to want your 
certificates to validate "nicely" on users own devices) or use internal 
CA and install its root certificate on all hosts using your IPA server. 
As I understand, --external-ca option should be used when you already 
have configured PKI infrastructure in your network (for example Active 
Directory Certificate Services) and spinning another internal CA is not 
a big deal. You've mentioned that there is already an Active Directory 
domain, so the last options seems the easiest one - internal CA root 
certificate can be deployed to Windows workstation using AD and IPA 
configured with external CA would automatically deploy internal root CA 
to Linux workstations on during ipa-client-install.


--
Best regards
Mateusz Małek

Network and Computer Systems Administrator
Intelligent Information Systems Group
Department of Computer Science
AGH University of Science and Technology

--
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] Declarative configuration options?

[Mike LoSapio]

Hi there,

Is there anyone out there with a good system for storing users,
groups, hosts, etc.. in some sort of version controlled repo w/ flat
files that could plug into "two-man" workflows for user-account
creation and privilege/group membership changes, etc.

There's some github projects out there to help installing FreeIPA
server and a few to get clients up and running, but nothing (that I
could find) for the on-going management of FreeIPA resources.



So in puppet world (just as an example) - I'd be looking for something
like a puppet-defined-type freeipa_user with all the attributes
required and more-importantly all the code-glue that puts it all
together...


Figured I'd ask if there if there's anything already out there before
I re-invent the wheel.


TIA,
--Mike

-- 
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] Certificate Issues

[Rob Crittenden]

Adam Lewis wrote:

Yup. I'm currently still sitting back in time. But any time I try to
resubmit either the ipaCert or the subsystemCert it errors out.

getcert list shows :
ca-error: Server at
"https://ipa.local.domain:9443/ca/agent/ca/profileProcess; replied: 1:
Authentication Error

And the debug log shows:
SignedAuditEventFactory: create()
message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
RA,O=MISS.ION] authentication failure
ReviewReqServlet: Invalid Credential.


I'd look at the lines above that for clues, and check the 389-ds access 
log. I assume it is finding an entry for uid=ipara, right?


The way the auth works as I understand it is dogtag first compares the 
serial number, issuer and subject of the provided certificate with the 
description attribute in the entry it finds in LDAP. Then it compares 
the full certificate. If things match up then you are authenticated. It 
then does some authorization work.


For reference, mine looks like:

dn: uid=ipara,ou=people,o=ipaca
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: cmsuser
uid: ipara
sn: ipara
cn: ipara
usertype: agentType
userstate: 1
userCertificate:: 
MIIDbTCCAlWgAwIBAgIBBzANBgkqhkiG9w0BAQsFADA2MRQwEgYDVQQKEwtH

 [snip]
 o0i1CCw1v++2tgvHiiZEEeeuOEMGEdXZfv4Xw=
description: 2;7;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA 
RA,O=EXAMPLE.COM



Those appear to be the most significant messages. I'm disconnected so
getting the full log info is difficult. If it's the only way let me know
and I'll see what I can do. Worst case it'll just take me a while to
re-type it.


Understood.




Thanks


On Mon, Aug 1, 2016 at 3:11 PM, Rob Crittenden > wrote:

Adam Lewis wrote:

Yup, It's just the text string. I don't know how much this
matters but
when I ran the start-tracking for the ipaCert it didn't generate
a new
certificate. I'm still working off of serial number 7, which is what
it's been since we installed IPA. Is there some way/reason for me to
generate a whole new ipaCert?


certmonger will take care of that when renewal happens.

Did you go back in time to when this cert was valid?

rob


Thanks

On Mon, Aug 1, 2016 at 3:00 PM, Rob Crittenden

>> wrote:

 Adam Lewis wrote:

 If you mean the usercertificate value from the ldapsearch
 command, then
 yes. That value matches the value from the certutil output.


 The usercertificate in LDAP had the BEGIN/END stripped, right?

 I'll cc a couple of the dogtag developers to see what they
think.

 rob


 Thanks

 On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden
 
>
  
>
   >>
  
 > 

Re: [Freeipa-users] Certificate Issues

[Adam Lewis]

Yup. I'm currently still sitting back in time. But any time I try to
resubmit either the ipaCert or the subsystemCert it errors out.

getcert list shows :
ca-error: Server at "
https://ipa.local.domain:9443/ca/agent/ca/profileProcess; replied: 1:
Authentication Error

And the debug log shows:
SignedAuditEventFactory: create()
message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
RA,O=MISS.ION] authentication failure
ReviewReqServlet: Invalid Credential.

Those appear to be the most significant messages. I'm disconnected so
getting the full log info is difficult. If it's the only way let me know
and I'll see what I can do. Worst case it'll just take me a while to
re-type it.

Thanks


On Mon, Aug 1, 2016 at 3:11 PM, Rob Crittenden  wrote:

> Adam Lewis wrote:
>
>> Yup, It's just the text string. I don't know how much this matters but
>> when I ran the start-tracking for the ipaCert it didn't generate a new
>> certificate. I'm still working off of serial number 7, which is what
>> it's been since we installed IPA. Is there some way/reason for me to
>> generate a whole new ipaCert?
>>
>
> certmonger will take care of that when renewal happens.
>
> Did you go back in time to when this cert was valid?
>
> rob
>
>
>> Thanks
>>
>> On Mon, Aug 1, 2016 at 3:00 PM, Rob Crittenden > > wrote:
>>
>> Adam Lewis wrote:
>>
>> If you mean the usercertificate value from the ldapsearch
>> command, then
>> yes. That value matches the value from the certutil output.
>>
>>
>> The usercertificate in LDAP had the BEGIN/END stripped, right?
>>
>> I'll cc a couple of the dogtag developers to see what they think.
>>
>> rob
>>
>>
>> Thanks
>>
>> On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden
>> 
>> >> wrote:
>>
>>  Adam Lewis wrote:
>>
>>  A quick update. We did some digging on the segfault
>> problem and
>>  I think
>>  it was due to having to update the trusts on the CA
>> cert. So we
>>  updated
>>  the certmonger package and certmonger now starts again.
>>  However we're kind of back to square one where we are
>> still
>>  getting the
>>  AUTH_FAIL messages in the debug log.
>>  I have verified that the ipara entry's serial number
>> and cert
>>  match the
>>  serial number and cert from the one in /etc/httpd/alias.
>>
>>
>>  How about the certificate PEM? Does it match the
>> usercertificate in
>>  the dogtag LDAP server?
>>
>>  rob
>>
>>
>>  Any other ideas?
>>
>>  Thanks!
>>
>>  On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis
>> 
>>  > >>
>>  >  > >
>>   Rob,
>>   Thanks for pointing me in the right direction.
>> However after
>>   following the instructions in the above mentioned
>> doc I
>>  noticed a
>>   few things that are odd and have a new problem.
>> The first
>>  odd thing
>>   I noticed is that when I run service pki-cad status
>> it
>>  shows that my
>>   PKI Subsystem Type is "CA Clone (Security Domain)"
>>   Shouldn't that say something like "CA Master"?
>>   Second, when I ran the "ipa-getcert resubmit -I
>> [ID]"
>>  commands they
>>   all produced the same AUTH_FAIL message in the
>> debug log.
>>
>>   Now the new problem...after pressing on and
>> restarting things
>>   certmonger fails to start with a segfault.
>>   Starting certmonger: /bin/bash: line 1: 64935
>> Segmentation
>>   fault  /usr/sbin/certmonger -S -p /var/run
>> certmonger.pid
>>
>>   Thanks!
>>
>>   On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden
>>  
>> >
>>   >  > 

Re: [Freeipa-users] Certificate Issues

[Rob Crittenden]

Adam Lewis wrote:

Yup, It's just the text string. I don't know how much this matters but
when I ran the start-tracking for the ipaCert it didn't generate a new
certificate. I'm still working off of serial number 7, which is what
it's been since we installed IPA. Is there some way/reason for me to
generate a whole new ipaCert?


certmonger will take care of that when renewal happens.

Did you go back in time to when this cert was valid?

rob



Thanks

On Mon, Aug 1, 2016 at 3:00 PM, Rob Crittenden > wrote:

Adam Lewis wrote:

If you mean the usercertificate value from the ldapsearch
command, then
yes. That value matches the value from the certutil output.


The usercertificate in LDAP had the BEGIN/END stripped, right?

I'll cc a couple of the dogtag developers to see what they think.

rob


Thanks

On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden

>> wrote:

 Adam Lewis wrote:

 A quick update. We did some digging on the segfault
problem and
 I think
 it was due to having to update the trusts on the CA
cert. So we
 updated
 the certmonger package and certmonger now starts again.
 However we're kind of back to square one where we are still
 getting the
 AUTH_FAIL messages in the debug log.
 I have verified that the ipara entry's serial number
and cert
 match the
 serial number and cert from the one in /etc/httpd/alias.


 How about the certificate PEM? Does it match the
usercertificate in
 the dogtag LDAP server?

 rob


 Any other ideas?

 Thanks!

 On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis

 >
  
>
   

Re: [Freeipa-users] Certificate Issues

[Adam Lewis]

Yup, It's just the text string. I don't know how much this matters but when
I ran the start-tracking for the ipaCert it didn't generate a new
certificate. I'm still working off of serial number 7, which is what it's
been since we installed IPA. Is there some way/reason for me to generate a
whole new ipaCert?

Thanks

On Mon, Aug 1, 2016 at 3:00 PM, Rob Crittenden  wrote:

> Adam Lewis wrote:
>
>> If you mean the usercertificate value from the ldapsearch command, then
>> yes. That value matches the value from the certutil output.
>>
>
> The usercertificate in LDAP had the BEGIN/END stripped, right?
>
> I'll cc a couple of the dogtag developers to see what they think.
>
> rob
>
>
>> Thanks
>>
>> On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden > > wrote:
>>
>> Adam Lewis wrote:
>>
>> A quick update. We did some digging on the segfault problem and
>> I think
>> it was due to having to update the trusts on the CA cert. So we
>> updated
>> the certmonger package and certmonger now starts again.
>> However we're kind of back to square one where we are still
>> getting the
>> AUTH_FAIL messages in the debug log.
>> I have verified that the ipara entry's serial number and cert
>> match the
>> serial number and cert from the one in /etc/httpd/alias.
>>
>>
>> How about the certificate PEM? Does it match the usercertificate in
>> the dogtag LDAP server?
>>
>> rob
>>
>>
>> Any other ideas?
>>
>> Thanks!
>>
>> On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis > 
>> >> wrote:
>>
>>  Rob,
>>  Thanks for pointing me in the right direction. However after
>>  following the instructions in the above mentioned doc I
>> noticed a
>>  few things that are odd and have a new problem. The first
>> odd thing
>>  I noticed is that when I run service pki-cad status it
>> shows that my
>>  PKI Subsystem Type is "CA Clone (Security Domain)"
>>  Shouldn't that say something like "CA Master"?
>>  Second, when I ran the "ipa-getcert resubmit -I [ID]"
>> commands they
>>  all produced the same AUTH_FAIL message in the debug log.
>>
>>  Now the new problem...after pressing on and restarting things
>>  certmonger fails to start with a segfault.
>>  Starting certmonger: /bin/bash: line 1: 64935 Segmentation
>>  fault  /usr/sbin/certmonger -S -p /var/run certmonger.pid
>>
>>  Thanks!
>>
>>  On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden
>> 
>>  >>
>>
>> wrote:
>>
>>  Lewis, Adam M CIV NSWCDD, H11 wrote:
>>
>>  We are currently dead in the water. Our OCSP, CA
>> Audit, CA
>>  Subsystem, and IPA RA certs expired as of 7/23/16.
>> I found
>>  and followed the instructions to the letter
>>
>> (
>> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0
>> )
>>  however the CA Subsystem and IPA RA certs will not
>> renew.
>>  I've backdated the server to make sure the system
>> was within
>>  the renewal window, but that has not help.
>>
>>
>>  Those are the wrong instructions.
>>
>>  You want this instead,
>> https://access.redhat.com/solutions/643753
>>
>>  A bunch of it is for 2.2 but it isn't exactly noted
>> which parts.
>>  A general rule is that you don't/shouldn't need to
>> directly
>>  tweak the dogtag configuration or do any of the
>> start-tracking
>>  work (though you may want to verify that what/if
>> anything you
>>  changed from that wrong doc).
>>
>>  When I run getcert list it reports:
>>  Ca-error: Sever at
>>  "https://:9443/ca/agent/ca/profileProcess"
>> replied: 1:
>>  Authentication Error
>>  for both the IPA RA and CA Subsystem certs
>>
>>  The debug log shows:
>>  SignedAuditEventFactory: create()
>>
>>
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
>>  RA,O=MISS.ION] authentication failure
>>  ReviewReqServlet: Invalid Credential.
>>
>>
>>

Re: [Freeipa-users] Certificate Issues

[Rob Crittenden]

Adam Lewis wrote:

If you mean the usercertificate value from the ldapsearch command, then
yes. That value matches the value from the certutil output.


The usercertificate in LDAP had the BEGIN/END stripped, right?

I'll cc a couple of the dogtag developers to see what they think.

rob



Thanks

On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden > wrote:

Adam Lewis wrote:

A quick update. We did some digging on the segfault problem and
I think
it was due to having to update the trusts on the CA cert. So we
updated
the certmonger package and certmonger now starts again.
However we're kind of back to square one where we are still
getting the
AUTH_FAIL messages in the debug log.
I have verified that the ipara entry's serial number and cert
match the
serial number and cert from the one in /etc/httpd/alias.


How about the certificate PEM? Does it match the usercertificate in
the dogtag LDAP server?

rob


Any other ideas?

Thanks!

On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis 
>> wrote:

 Rob,
 Thanks for pointing me in the right direction. However after
 following the instructions in the above mentioned doc I
noticed a
 few things that are odd and have a new problem. The first
odd thing
 I noticed is that when I run service pki-cad status it
shows that my
 PKI Subsystem Type is "CA Clone (Security Domain)"
 Shouldn't that say something like "CA Master"?
 Second, when I ran the "ipa-getcert resubmit -I [ID]"
commands they
 all produced the same AUTH_FAIL message in the debug log.

 Now the new problem...after pressing on and restarting things
 certmonger fails to start with a segfault.
 Starting certmonger: /bin/bash: line 1: 64935 Segmentation
 fault  /usr/sbin/certmonger -S -p /var/run certmonger.pid

 Thanks!

 On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden

 >>
wrote:

 Lewis, Adam M CIV NSWCDD, H11 wrote:

 We are currently dead in the water. Our OCSP, CA
Audit, CA
 Subsystem, and IPA RA certs expired as of 7/23/16.
I found
 and followed the instructions to the letter


(http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0)
 however the CA Subsystem and IPA RA certs will not
renew.
 I've backdated the server to make sure the system
was within
 the renewal window, but that has not help.


 Those are the wrong instructions.

 You want this instead,
https://access.redhat.com/solutions/643753

 A bunch of it is for 2.2 but it isn't exactly noted
which parts.
 A general rule is that you don't/shouldn't need to directly
 tweak the dogtag configuration or do any of the
start-tracking
 work (though you may want to verify that what/if
anything you
 changed from that wrong doc).

 When I run getcert list it reports:
 Ca-error: Sever at
 "https://:9443/ca/agent/ca/profileProcess"
replied: 1:
 Authentication Error
 for both the IPA RA and CA Subsystem certs

 The debug log shows:
 SignedAuditEventFactory: create()


message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
 RA,O=MISS.ION] authentication failure
 ReviewReqServlet: Invalid Credential.


 The place to start is to get the serial # of the ipaCert:

 # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial

 Now get the user from the dogtag LDAP server:

 # ldapsearch -h `hostname` -p 7389 -x -D 'cn=directory
manager'
 -W -b uid=ipara,ou=People,o=ipaca description

 The format is 2;;;

 See if the serial # matches ipaCert. I'm guessing it won't.
 Follow the instructions on the page I cited to update
the entry
 with the current certificate and serial # values. That
should
 get you going.

 rob



  

Re: [Freeipa-users] updating certificates

[Josh]

Hi Rob,

Just a quick summary on my certificate renew experience.

I started with a worst case scenario assumption - original CSR and key 
is no longer available.

1. export old certificate in pkcs12 format
pk12util -d /etc/httpd/alias -n 'certificate alias' -o /tmp/ipa.p12 -k 
/etc/httpd/alias/pwdfile.txt

2. extract original certificate key
openssl pkcs12 -in /tmp/ipa.p12 -out /tmp/ipa.key -nocerts
3. generate new CSR
openssl req -out CSR.csr -key  /tmp/ipa.key -new

above commands just for reference and require significant interactive input.
I wonder if anyone can wrap all in one script.

Regarding installing new certificate I found that simplest method is to 
delete expired certificate first and import new one using the same 
alias, adding intermediate certificate if changed. Steps are identical 
for both apache and directory server.

1. certutil -D -d /etc/httpd/alias -n original_alias
2. certutil -A -n Intermediate -d /etc/httpd/alias -a -i 
intermediate.pem -t "C,,"
3. certutil -A -n original_alias -d /etc/httpd/alias -t u,u,u -a -i 
myipanew.pem



Josh.

On 07/11/2016 10:10 AM, Rob Crittenden wrote:

j...@use.startmail.com wrote:
On Tuesday, June 28, 2016 10:50 AM, Rob Crittenden 
 wrote:

j...@use.startmail.com wrote:

Greetings,

About a year ago I installed my freeipa server with certificates from
startssl using command line options --dirsrv-cert-file 
--http-cert-file

etc.
The certificate is about to expire, what is the proper way to 
update it

in all places?


It depends on whether you kept the original CSR or not. If you kept the
original CSR and are just renewing the certificate(s) then when you get
the new one, use certutil to add the updated cert to the appropriate 
NSS

database like:

# certutil -A -n Server-Cert -d /etc/httpd/alias -t u,u,u -a -i
/path/to/new.crt



Rob,

Thank you, that worked just fine, except that I had to update an 
intermediate certificate as well.


Two questions, please:

1. I noticed a strange discrepancy in behavior between 
/etc/httpd/alias and /etc/dirsrv/slapd-domain.
In both places original intermediate certificate is listed with empty 
",," trust attributes so I initially added new intermediate 
certificate with empty attributes as well.
certutils -V showed valid certificate in /etc/httpd/alias and not 
trusted in /etc/dirsrv/slapd-domain so I had to modify intermediate 
certificate with -t "C,,"


Hmm, not sure. Did the CA chain change in between the issuance of the 
two certs?


Adding a new certificate shouldn't affect the trust of any other certs 
so I'm not sure what happened. It could be that those subordinate CAs 
were loaded the first time incorrectly but weren't used so it wasn't 
noticed, I'm not really sure.


2. Just out of curiosity I wanted to list private keys and is 
prompted for a password:

# certutil -K -d /etc/httpd/alias/
certutil: Checking token "NSS Certificate DB" in slot "NSS User 
Private Key and Certificate Services"

Enter Password or Pin for "NSS Certificate DB":

Which one of the many provided by a user passwords is used by 
ipa-server-install command during NSS database initialization?


In each NSS directory there is a pwdfile.txt which contains the PIN 
for the internal token. You can add -f /etc/httpd/alias/pwdfile.txt to 
your command to list the private keys.


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] ipa-server-install --external-cert-file and exporting dogtag certificates

[Petr Vobornik]

On 07/31/2016 07:45 AM, Richard Harmonson wrote:
> I having challenges resuming ipa-server-install --external-ca. I am 
> reasonably 
> confident I am not providing the right certificate and/or format from my 
> off-line root CA using 389 and Dogtag.
> 
> Does anyone have instructions on how to accomplish the task of exporting the 
> correct certificates in the expected format?
> 
> Thank you.
> 

The IPA procedure with prerequisites is described at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-external-ca

Or are you rather asking for specific PKI instructions?

e.g.
*
http://pki.fedoraproject.org/wiki/PKI_Certificate_CLI#Submitting_a_Certificate_Request

*
http://pki.fedoraproject.org/wiki/CA_Certificate_Profiles#caCACert:_Manual_Certificate_Manager_Signing_Certificate_Enrollment
-- 
Petr Vobornik

-- 
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] Certificate Issues

[Adam Lewis]

If you mean the usercertificate value from the ldapsearch command, then
yes. That value matches the value from the certutil output.

Thanks

On Mon, Aug 1, 2016 at 11:18 AM, Rob Crittenden  wrote:

> Adam Lewis wrote:
>
>> A quick update. We did some digging on the segfault problem and I think
>> it was due to having to update the trusts on the CA cert. So we updated
>> the certmonger package and certmonger now starts again.
>> However we're kind of back to square one where we are still getting the
>> AUTH_FAIL messages in the debug log.
>> I have verified that the ipara entry's serial number and cert match the
>> serial number and cert from the one in /etc/httpd/alias.
>>
>
> How about the certificate PEM? Does it match the usercertificate in the
> dogtag LDAP server?
>
> rob
>
>
>> Any other ideas?
>>
>> Thanks!
>>
>> On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis > > wrote:
>>
>> Rob,
>> Thanks for pointing me in the right direction. However after
>> following the instructions in the above mentioned doc I noticed a
>> few things that are odd and have a new problem. The first odd thing
>> I noticed is that when I run service pki-cad status it shows that my
>> PKI Subsystem Type is "CA Clone (Security Domain)"
>> Shouldn't that say something like "CA Master"?
>> Second, when I ran the "ipa-getcert resubmit -I [ID]" commands they
>> all produced the same AUTH_FAIL message in the debug log.
>>
>> Now the new problem...after pressing on and restarting things
>> certmonger fails to start with a segfault.
>> Starting certmonger: /bin/bash: line 1: 64935 Segmentation
>> fault  /usr/sbin/certmonger -S -p /var/run certmonger.pid
>>
>> Thanks!
>>
>> On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden > > wrote:
>>
>> Lewis, Adam M CIV NSWCDD, H11 wrote:
>>
>> We are currently dead in the water. Our OCSP, CA Audit, CA
>> Subsystem, and IPA RA certs expired as of 7/23/16. I found
>> and followed the instructions to the letter
>> (
>> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0
>> )
>> however the CA Subsystem and IPA RA certs will not renew.
>> I've backdated the server to make sure the system was within
>> the renewal window, but that has not help.
>>
>>
>> Those are the wrong instructions.
>>
>> You want this instead, https://access.redhat.com/solutions/643753
>>
>> A bunch of it is for 2.2 but it isn't exactly noted which parts.
>> A general rule is that you don't/shouldn't need to directly
>> tweak the dogtag configuration or do any of the start-tracking
>> work (though you may want to verify that what/if anything you
>> changed from that wrong doc).
>>
>> When I run getcert list it reports:
>> Ca-error: Sever at
>> "https://:9443/ca/agent/ca/profileProcess" replied: 1:
>> Authentication Error
>> for both the IPA RA and CA Subsystem certs
>>
>> The debug log shows:
>> SignedAuditEventFactory: create()
>>
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
>> RA,O=MISS.ION] authentication failure
>> ReviewReqServlet: Invalid Credential.
>>
>>
>> The place to start is to get the serial # of the ipaCert:
>>
>> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
>>
>> Now get the user from the dogtag LDAP server:
>>
>> # ldapsearch -h `hostname` -p 7389 -x -D 'cn=directory manager'
>> -W -b uid=ipara,ou=People,o=ipaca description
>>
>> The format is 2;;;
>>
>> See if the serial # matches ipaCert. I'm guessing it won't.
>> Follow the instructions on the page I cited to update the entry
>> with the current certificate and serial # values. That should
>> get you going.
>>
>> rob
>>
>>
>>
>> We are kind of in deep doo-doo until this gets resolved.
>>
>> We are running ipa-server-3.0.0-47.el6_7.2 on RHEL 6.5
>>
>> Any thoughts?
>>
>> Thanks!
>>
>> Adam M. Lewis
>>
>>
>>
>>
>> --
>> 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
>>
>>
>>
>>
>> --
>> Adam M. Lewis
>> alewis...@gmail.com 
>> 10807 Allie Place
>> Fredericksburg, VA 22408
>> 540-412-8643 
>>
>>
>>
>>
>>
>> --
>> Adam M. Lewis
>> alewis...@gmail.com 
>> 10807 Allie Place
>> Fredericksburg, VA 22408
>> 540-412-8643
>>

Re: [Freeipa-users] Certificate Issues

[Rob Crittenden]

Adam Lewis wrote:

A quick update. We did some digging on the segfault problem and I think
it was due to having to update the trusts on the CA cert. So we updated
the certmonger package and certmonger now starts again.
However we're kind of back to square one where we are still getting the
AUTH_FAIL messages in the debug log.
I have verified that the ipara entry's serial number and cert match the
serial number and cert from the one in /etc/httpd/alias.


How about the certificate PEM? Does it match the usercertificate in the 
dogtag LDAP server?


rob



Any other ideas?

Thanks!

On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis > wrote:

Rob,
Thanks for pointing me in the right direction. However after
following the instructions in the above mentioned doc I noticed a
few things that are odd and have a new problem. The first odd thing
I noticed is that when I run service pki-cad status it shows that my
PKI Subsystem Type is "CA Clone (Security Domain)"
Shouldn't that say something like "CA Master"?
Second, when I ran the "ipa-getcert resubmit -I [ID]" commands they
all produced the same AUTH_FAIL message in the debug log.

Now the new problem...after pressing on and restarting things
certmonger fails to start with a segfault.
Starting certmonger: /bin/bash: line 1: 64935 Segmentation
fault  /usr/sbin/certmonger -S -p /var/run certmonger.pid

Thanks!

On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden > wrote:

Lewis, Adam M CIV NSWCDD, H11 wrote:

We are currently dead in the water. Our OCSP, CA Audit, CA
Subsystem, and IPA RA certs expired as of 7/23/16. I found
and followed the instructions to the letter

(http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0)
however the CA Subsystem and IPA RA certs will not renew.
I've backdated the server to make sure the system was within
the renewal window, but that has not help.


Those are the wrong instructions.

You want this instead, https://access.redhat.com/solutions/643753

A bunch of it is for 2.2 but it isn't exactly noted which parts.
A general rule is that you don't/shouldn't need to directly
tweak the dogtag configuration or do any of the start-tracking
work (though you may want to verify that what/if anything you
changed from that wrong doc).

When I run getcert list it reports:
Ca-error: Sever at
"https://:9443/ca/agent/ca/profileProcess" replied: 1:
Authentication Error
for both the IPA RA and CA Subsystem certs

The debug log shows:
SignedAuditEventFactory: create()

message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
RA,O=MISS.ION] authentication failure
ReviewReqServlet: Invalid Credential.


The place to start is to get the serial # of the ipaCert:

# certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial

Now get the user from the dogtag LDAP server:

# ldapsearch -h `hostname` -p 7389 -x -D 'cn=directory manager'
-W -b uid=ipara,ou=People,o=ipaca description

The format is 2;;;

See if the serial # matches ipaCert. I'm guessing it won't.
Follow the instructions on the page I cited to update the entry
with the current certificate and serial # values. That should
get you going.

rob



We are kind of in deep doo-doo until this gets resolved.

We are running ipa-server-3.0.0-47.el6_7.2 on RHEL 6.5

Any thoughts?

Thanks!

Adam M. Lewis




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




--
Adam M. Lewis
alewis...@gmail.com 
10807 Allie Place
Fredericksburg, VA 22408
540-412-8643 





--
Adam M. Lewis
alewis...@gmail.com 
10807 Allie Place
Fredericksburg, VA 22408
540-412-8643






--
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] Certificate Issues

[Adam Lewis]

A quick update. We did some digging on the segfault problem and I think it
was due to having to update the trusts on the CA cert. So we updated the
certmonger package and certmonger now starts again.
However we're kind of back to square one where we are still getting the
AUTH_FAIL messages in the debug log.
I have verified that the ipara entry's serial number and cert match the
serial number and cert from the one in /etc/httpd/alias.

Any other ideas?

Thanks!

On Mon, Aug 1, 2016 at 9:17 AM, Adam Lewis  wrote:

> Rob,
> Thanks for pointing me in the right direction. However after following the
> instructions in the above mentioned doc I noticed a few things that are odd
> and have a new problem. The first odd thing I noticed is that when I run
> service pki-cad status it shows that my PKI Subsystem Type is "CA Clone
> (Security Domain)"
> Shouldn't that say something like "CA Master"?
> Second, when I ran the "ipa-getcert resubmit -I [ID]" commands they all
> produced the same AUTH_FAIL message in the debug log.
>
> Now the new problem...after pressing on and restarting things certmonger
> fails to start with a segfault.
> Starting certmonger: /bin/bash: line 1: 64935 Segmentation fault
> /usr/sbin/certmonger -S -p /var/run certmonger.pid
>
> Thanks!
>
> On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden 
> wrote:
>
>> Lewis, Adam M CIV NSWCDD, H11 wrote:
>>
>>> We are currently dead in the water. Our OCSP, CA Audit, CA Subsystem,
>>> and IPA RA certs expired as of 7/23/16. I found and followed the
>>> instructions to the letter (
>>> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0)
>>> however the CA Subsystem and IPA RA certs will not renew. I've backdated
>>> the server to make sure the system was within the renewal window, but that
>>> has not help.
>>>
>>
>> Those are the wrong instructions.
>>
>> You want this instead, https://access.redhat.com/solutions/643753
>>
>> A bunch of it is for 2.2 but it isn't exactly noted which parts. A
>> general rule is that you don't/shouldn't need to directly tweak the dogtag
>> configuration or do any of the start-tracking work (though you may want to
>> verify that what/if anything you changed from that wrong doc).
>>
>> When I run getcert list it reports:
>>> Ca-error: Sever at "https://:9443/ca/agent/ca/profileProcess"
>>> replied: 1: Authentication Error
>>> for both the IPA RA and CA Subsystem certs
>>>
>>> The debug log shows:
>>> SignedAuditEventFactory: create()
>>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
>>> RA,O=MISS.ION] authentication failure
>>> ReviewReqServlet: Invalid Credential.
>>>
>>
>> The place to start is to get the serial # of the ipaCert:
>>
>> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
>>
>> Now get the user from the dogtag LDAP server:
>>
>> # ldapsearch -h `hostname` -p 7389 -x -D 'cn=directory manager' -W -b
>> uid=ipara,ou=People,o=ipaca description
>>
>> The format is 2;;;
>>
>> See if the serial # matches ipaCert. I'm guessing it won't. Follow the
>> instructions on the page I cited to update the entry with the current
>> certificate and serial # values. That should get you going.
>>
>> rob
>>
>>
>>
>>> We are kind of in deep doo-doo until this gets resolved.
>>>
>>> We are running ipa-server-3.0.0-47.el6_7.2 on RHEL 6.5
>>>
>>> Any thoughts?
>>>
>>> Thanks!
>>>
>>> Adam M. Lewis
>>>
>>>
>>>
>>>
>> --
>> 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
>>
>
>
>
> --
> Adam M. Lewis
> alewis...@gmail.com
> 10807 Allie Place
> Fredericksburg, VA 22408
> 540-412-8643
>
>
>


-- 
Adam M. Lewis
alewis...@gmail.com
10807 Allie Place
Fredericksburg, VA 22408
540-412-8643
-- 
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] Slow logins with multi site replication

[Neal Harrington | i-Neda Ltd]

Hi,


I am experiencing slow logins and sudo authentication for servers joined to my 
FreeIPA domain. I have been following the other recent thread on slow logins 
and believe my issue is different.


I have replication setup with 2 FreeIPA servers at each of 3 sites. The 
replication is working well and I am able to login correctly on client servers 
with correct sudo permissions etc. Logins seem to take a long time however. 
There seems to be some kind of DNS/connection timeout issues, see the example 
below where the client times out on the auth01 server, then retries and 
connects. I have also seen it switch to an alternate IPA server on timeout. 
Total delay in this example is about 10 seconds however it can take longer 
(approx 30 seconds). It is worth mentioning that client servers in each site 
cannot connect to IPA servers is a different site - however in the example 
below the auth01 IPA server is in the same site as the client server. I'm not 
sure if there is any way to make the IPA clients site aware so they prefer to 
log in to a local server?


On the IPA servers themselves there is no noticeable delay and once I have 
authenticated with sudo once, subsequent attempts in the same login are also 
near instant. I have not been able to find any reason for this delay in any 
logs (which probably just means I'm not looking in the right place).


DNS servers are running on each IPA server and responding well whenever I have 
tested.


IPA Servers: CentOS 7.2.1511 running IPA 4.2.0 (from standard CentOS repo)

Client servers: Ubuntu 14.04 running IPA 3.3.4 (From standard Ubuntu repo)


Any comments or suggestions greatly appreciated.


Thanks,

Neal.


Example sssd log for a "sudo -l" attempt.

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [be_get_account_info] (0x0100): 
Got request for [3][1][name=neal]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] 
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain 
SID from [(null)]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] 
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain 
SID from [(null)]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [sdap_attrs_get_sid_str] 
(0x0080): No [objectSIDString] attribute while id-mapping. [0][Success]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] 
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain 
SID from [(null)]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] 
[sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain 
SID from [(null)]

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [acctinfo_callback] (0x0100): 
Request processed. Returned 0,0,Success

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [be_pam_handler] (0x0100): Got 
request with the following data

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
command: PAM_AUTHENTICATE

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
domain: fqdn.com

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): user: 
neal

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
service: sudo

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): tty: 
/dev/pts/3

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
ruser: neal

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): rhost:

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
authtok type: 1

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
newauthtok type: 0

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): priv: 0

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [pam_print_data] (0x0100): 
cli_pid: 7429

(Mon Aug 1 14:39:53 2016) [sssd[be[fqdn.com]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'IPA'

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_child_timeout] (0x0040): 
Timeout for child [7430] reached. In case KDC is distant or network is slow you 
may consider increasing value of krb5_auth_timeout.

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [krb5_auth_done] (0x0020): child 
timed out!

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [fo_set_port_status] (0x0100): 
Marking port 389 of server 'auth01.fqdn.com' as 'not working'

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'IPA'

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [child_sig_handler] (0x0020): 
waitpid did not found a child with changed status.

(Mon Aug 1 14:39:59 2016) [sssd[be[fqdn.com]]] [child_sig_handler] (0x0020): 
child [7430] was terminated by signal [9].

(Mon Aug 1 14:40:04 2016) [sssd[be[fqdn.com]]] [fo_set_port_status] (0x0100): 
Marking port 0 of server 'auth01.fqdn.com' as 'working'

(Mon Aug 1 14:40:04 2016) [sssd[be[fqdn.com]]] [set_server_common_status] 
(0x0100): Marking server 'auth01.fqdn.com' as 'working'

Re: [Freeipa-users] certificates expired - won't renew

[Rob Crittenden]

sipazzo wrote:

I set time back on master ca and was able to renew its certs except for
one that has yet to expire but should have renewed. I tried to resubmit
it but it still does not renew and status says NEED_CSR_GEN_TOKEN. We do
have a go daddy cert we use as well but it is valid still. Is it because
of the nickname mismatches? I am not sure how to fix that.


There is no cert to renew. You replaced the IPA-issued certificates with 
GoDaddy certs. The NSS_CSR_GEN_TOKEN is there because there is no 
private key for a certificate named Server-Cert so certmonger doesn't 
know what to do. To make this go away you can tell certmonger to stop 
tracking this non-existent certificate with something like:


# ipa-getcert stop-tracking -i 

certmonger cannot auto-renew your GoDaddy certficate.

and see below.



ipa1-example.com

Request ID '20140729215756':
 status: NEED_CSR_GEN_TOKEN
 stuck: yes
 key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=EXAMPLE.COM
 subject: CN=ipa1.example.com,O=EXAMPLE.COM
 expires: 2016-07-29 20:39: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 EXAMPLE-COM
 track: yes
 auto-renew: yes

certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

NWF_GD   u,u,u
CN=Certificate Authority,O=EXAMPLE.COM  CT,,C
OU=Go Daddy Class 2 Certification Authority,O=The Go Daddy Group\,
Inc.,C=US CT,,C
GD_CACT,,C
CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com\,
Inc.,L=Scottsdale,ST=Arizona,C=US CT,,C


certutil -L -d /etc/dirsrv/slapd-PKI-IPA/

Certificate Nickname
O=EXAMPLE.COM Trust Attributes

SSL,S/MIME,JAR/XPI

EXAMPLE.COM IPA CA  CT,C,
Server-Cert  u,u,u


certutil -L -d /etc/httpd/alias/

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

EXAMPLE.COM IPA CA   CT,C,
ipaCert  u,u,u
Server-Cert  u,u,u

My other servers had varying degrees of success with their expired
certificates, I have one server that would not renew 6 of its certs, 1
that would not renew 2 of its certs and 1 that would not renew 1 of its
certs. These are examples of the last two - I will save the one that
won't renew 6 as I am hoping I can apply same steps to those failures.

*ipa2.example.com - 2 won't renew - one CA_unreachable even after
successful restart of services and one NEED_CSR_GEN_TOKEN*

Request ID '20140729215756':
 status: NEED_CSR_GEN_TOKEN
 stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=EXAMPLE.COM
 subject: CN=ipa2.example.com,O=EXAMPLE.COM
 expires: 2016-07-29 20:39: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 EXAMPLE-COM
 track: yes
 auto-renew: yes


I'm guessing same GoDaddy issue.


Request ID '20140729215712':
 status: CA_UNREACHABLE
ca-error: Error 60 connecting to
https://ipa2.example.com:9443/ca/agent/ca/profileReview: Peer
certificate cannot be authenticated with known CA certificates.
 stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB',pin set
 certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert
cert-pki-ca',token='NSS Certificate DB'
 CA: dogtag-ipa-renew-agent
 issuer: CN=Certificate Authority,O=EXAMPLE.COM
 subject: CN=ipa2.example.com,O=EXAMPLE.COM
 expires: 2016-07-18 21:57:06 UTC
 key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
 eku: id-kp-serverAuth
 pre-save command:
 post-save command:
 track: yes
 auto-renew: yes


You should update certmonger. The version you have doesn't include the 
pre/save commands in its output.

Re: [Freeipa-users] Certificate Issues

[Adam Lewis]

Rob,
Thanks for pointing me in the right direction. However after following the
instructions in the above mentioned doc I noticed a few things that are odd
and have a new problem. The first odd thing I noticed is that when I run
service pki-cad status it shows that my PKI Subsystem Type is "CA Clone
(Security Domain)"
Shouldn't that say something like "CA Master"?
Second, when I ran the "ipa-getcert resubmit -I [ID]" commands they all
produced the same AUTH_FAIL message in the debug log.

Now the new problem...after pressing on and restarting things certmonger
fails to start with a segfault.
Starting certmonger: /bin/bash: line 1: 64935 Segmentation fault
/usr/sbin/certmonger -S -p /var/run certmonger.pid

Thanks!

On Thu, Jul 28, 2016 at 3:36 PM, Rob Crittenden  wrote:

> Lewis, Adam M CIV NSWCDD, H11 wrote:
>
>> We are currently dead in the water. Our OCSP, CA Audit, CA Subsystem, and
>> IPA RA certs expired as of 7/23/16. I found and followed the instructions
>> to the letter (
>> http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Procedure_in_FreeIPA_.3C_4.0)
>> however the CA Subsystem and IPA RA certs will not renew. I've backdated
>> the server to make sure the system was within the renewal window, but that
>> has not help.
>>
>
> Those are the wrong instructions.
>
> You want this instead, https://access.redhat.com/solutions/643753
>
> A bunch of it is for 2.2 but it isn't exactly noted which parts. A general
> rule is that you don't/shouldn't need to directly tweak the dogtag
> configuration or do any of the start-tracking work (though you may want to
> verify that what/if anything you changed from that wrong doc).
>
> When I run getcert list it reports:
>> Ca-error: Sever at "https://:9443/ca/agent/ca/profileProcess"
>> replied: 1: Authentication Error
>> for both the IPA RA and CA Subsystem certs
>>
>> The debug log shows:
>> SignedAuditEventFactory: create()
>> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA
>> RA,O=MISS.ION] authentication failure
>> ReviewReqServlet: Invalid Credential.
>>
>
> The place to start is to get the serial # of the ipaCert:
>
> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
>
> Now get the user from the dogtag LDAP server:
>
> # ldapsearch -h `hostname` -p 7389 -x -D 'cn=directory manager' -W -b
> uid=ipara,ou=People,o=ipaca description
>
> The format is 2;;;
>
> See if the serial # matches ipaCert. I'm guessing it won't. Follow the
> instructions on the page I cited to update the entry with the current
> certificate and serial # values. That should get you going.
>
> rob
>
>
>
>> We are kind of in deep doo-doo until this gets resolved.
>>
>> We are running ipa-server-3.0.0-47.el6_7.2 on RHEL 6.5
>>
>> Any thoughts?
>>
>> Thanks!
>>
>> Adam M. Lewis
>>
>>
>>
>>
> --
> 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
>



-- 
Adam M. Lewis
alewis...@gmail.com
10807 Allie Place
Fredericksburg, VA 22408
540-412-8643
-- 
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] Moving from ca to ca-less without pki

[David Kupka]

On 29/07/16 15:35, Andreas Ladanyi wrote:

Hi,

is it simply possible to move from ca to a ca-less environment in ipa ?
Because its ok for me to only use certificates in web and ldap
components. I use freeipa 4.2 , fedora 23.

regards,
Andreas



Hello Andreas!

There is no tool that would do this for you, yet. You can manually 
remove CS entries from LDAP, remove CS instance, stop tracking 
certificates in certmonger and replace certificates for apache and 
dirsrv. But be very cautious any mistake may destroy the whole freeipa 
server and all data stored there.


ipa-cacert-manage does the opposite (installing CS on CA-less freeipa 
server). Feel free to file an RFE https://fedorahosted.org/freeipa/newticket


--
David Kupka

--
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] slow login with freeipa 4.2.0

[Petr Spacek]

On 1.8.2016 09:08, Jakub Hrozek wrote:
> On Sat, Jul 30, 2016 at 02:02:56PM +0530, Rakesh Rajasekharan wrote:
>> Thanks Jakub for the detailed analysis... with those inputs , I was able to
>> nail down the issue.
>>
>> I had migrated this host from openldap to freeipa.. However, nslcd daemon
>> was still running and the sylog pointed me to the error "unable to contact
>> the earlier openldap server" and it spent some time there...
>>
>> So, I stopped nslcd and now logins have improved drastically to around 5s
>>
>> date;ssh testuser@localhost
>> Sat Jul 30 08:09:13 UTC 2016
>> testuser@localhost's password:
>> Last login: Sat Jul 30 08:08:55 2016 from 127.0.0.1
>> [p-rakeshpillai@prod1-admintools-1c :~] date
>> Sat Jul 30 08:09:18 UTC 2016
>>
>>
>> For the ipa_hostname entry in sssd.conf, that gets auto populated entered
>> everytime I run ipa-client-install .
>>
>> I run the below command to setup ipa client
>>
>> ipa-client-install --domain=xyz.xom --server=ipa-master-int.xyz.xom
>> --realm=xyz.xom -p admin --password=mypass--mkhomedir --hostname=10.65.16.4
>> --no-ssh --no-sshd -N -f -U

Hostname == IP address will break Kerberos authentication in cases where
client wants to connect using DNS name instead of IP address.

E.g. it will break "ssh user@server" where server is the machine you installed
using the command above.

Petr^2 Spacek

>>
>> Notice that, In the hostname argument, I am passing the IP address. Hope
>> thats fine, its actually working fine on around 2000+ servers in my
>> environment.
> 
> I wonder if this works only by accident. Even if you run
> ipa-client-install --hostname then you'll see in the help this is
> supposed to be FQDN. Kerberos got less picky about hostnames in the
> recent releases, but still..
> 
>>
>> I had earlier tried with servername.domain ( qa-test1.yyz.com as the
>> hostname ) and my servers hostname would get changed to  qa-test1.yyz.com .
>> However, we do our deployments on glassfish and glassfish somehow started
>> having issue everytime we restart glassfish ( not an expert with glassfish
>> ) so not sure whats wrong there.
>>
>> With this approach , my hostname is now my ipaddress and  things are
>> working fine both at galssfish and IPA side.
>> But just want to confirm its ok to do that
>>
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 29, 2016 at 5:10 PM, Jakub Hrozek  wrote:
>>
>>> On Tue, Jul 26, 2016 at 06:07:10PM +0530, Rakesh Rajasekharan wrote:
> Any change that it's running on a VM? If so, check your entropy:

> cat /proc/sys/kernel/random/entropy_avail

> If it's low (like < 1k), install haveged.

 this indeed is vm , am running it on azure . However, I have a similar
>>> set
 up running on aws which works completely fine
>>>
>>> Sorry about the delay in replying..
>>>

 The entropy was low, around 180, I installed haveged and now its above 3k
 cat /proc/sys/kernel/random/entropy_avail
 3178

 The timing though is still the same around 19s
>>>
>>> I have some comments inline about the config and logs.
>>>

 @jakub, i am reattaching the logs.

 The dns resoltion seems fast when I check using dig

 below is my sssd.conf
 [domain/xyz.com]
 selinux_provider=none
 krb5_auth_timeout = 20
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = xyz.com
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ldap_tls_cacert = /etc/ipa/ca.crt
 ipa_hostname = 10.65.16.4
>>>
>>> The ipa_hostname value is wrong. It's meant for systems where hostname
>>> reports a different name that what is the name the host is registered as
>>> in IPA. Including an IP address there doesn't make much sense.
>>>
 chpass_provider = ipa
 ipa_server = ipa-master-in.xyz.com
 dns_discovery_domain = xyz.com
 ignore_group_members=True
 ldap_purge_cache_timeout = 0
 debug_level=8
 [sssd]
 services = nss, sudo, pam, ssh
 config_file_version = 2

 domains = xyz.com
 [nss]
 homedir_substring = /home

 [pam]
 pam_id_timeout = 3

 [sudo]

 [autofs]

 [ssh]

 [pac]

 [ifp]



 And here is the login times and logs

 [root@ipa-client-1 :~] date;ssh testuser@localhost
 Tue Jul 26 12:06:37 UTC 2016
 testuser@localhost's password:
 Last login: Tue Jul 26 12:03:53 2016 from 127.0.0.1
 [testuser@ipa-client-1 :~] date
 Tue Jul 26 12:06:55 UTC 2016


 sssd_domain logs

 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_message_handler]
 (0x2000): Received SBUS method
 org.freedesktop.sssd.dataprovider.getAccountInfo on path
 /org/freedesktop/sssd/dataprovider
 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_get_sender_id_send]
 (0x2000): Not a sysbus message, quit
 (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] 

Re: [Freeipa-users] slow login with freeipa 4.2.0

[Jakub Hrozek]

On Sat, Jul 30, 2016 at 02:02:56PM +0530, Rakesh Rajasekharan wrote:
> Thanks Jakub for the detailed analysis... with those inputs , I was able to
> nail down the issue.
> 
> I had migrated this host from openldap to freeipa.. However, nslcd daemon
> was still running and the sylog pointed me to the error "unable to contact
> the earlier openldap server" and it spent some time there...
> 
> So, I stopped nslcd and now logins have improved drastically to around 5s
> 
> date;ssh testuser@localhost
> Sat Jul 30 08:09:13 UTC 2016
> testuser@localhost's password:
> Last login: Sat Jul 30 08:08:55 2016 from 127.0.0.1
> [p-rakeshpillai@prod1-admintools-1c :~] date
> Sat Jul 30 08:09:18 UTC 2016
> 
> 
> For the ipa_hostname entry in sssd.conf, that gets auto populated entered
> everytime I run ipa-client-install .
> 
> I run the below command to setup ipa client
> 
> ipa-client-install --domain=xyz.xom --server=ipa-master-int.xyz.xom
> --realm=xyz.xom -p admin --password=mypass--mkhomedir --hostname=10.65.16.4
> --no-ssh --no-sshd -N -f -U
> 
> Notice that, In the hostname argument, I am passing the IP address. Hope
> thats fine, its actually working fine on around 2000+ servers in my
> environment.

I wonder if this works only by accident. Even if you run
ipa-client-install --hostname then you'll see in the help this is
supposed to be FQDN. Kerberos got less picky about hostnames in the
recent releases, but still..

> 
> I had earlier tried with servername.domain ( qa-test1.yyz.com as the
> hostname ) and my servers hostname would get changed to  qa-test1.yyz.com .
> However, we do our deployments on glassfish and glassfish somehow started
> having issue everytime we restart glassfish ( not an expert with glassfish
> ) so not sure whats wrong there.
> 
> With this approach , my hostname is now my ipaddress and  things are
> working fine both at galssfish and IPA side.
> But just want to confirm its ok to do that
> 
> 
> Thanks,
> Rakesh
> 
> 
> 
> 
> 
> 
> On Fri, Jul 29, 2016 at 5:10 PM, Jakub Hrozek  wrote:
> 
> > On Tue, Jul 26, 2016 at 06:07:10PM +0530, Rakesh Rajasekharan wrote:
> > > > Any change that it's running on a VM? If so, check your entropy:
> > >
> > > > cat /proc/sys/kernel/random/entropy_avail
> > >
> > > > If it's low (like < 1k), install haveged.
> > >
> > > this indeed is vm , am running it on azure . However, I have a similar
> > set
> > > up running on aws which works completely fine
> >
> > Sorry about the delay in replying..
> >
> > >
> > > The entropy was low, around 180, I installed haveged and now its above 3k
> > > cat /proc/sys/kernel/random/entropy_avail
> > > 3178
> > >
> > > The timing though is still the same around 19s
> >
> > I have some comments inline about the config and logs.
> >
> > >
> > > @jakub, i am reattaching the logs.
> > >
> > > The dns resoltion seems fast when I check using dig
> > >
> > > below is my sssd.conf
> > > [domain/xyz.com]
> > > selinux_provider=none
> > > krb5_auth_timeout = 20
> > > cache_credentials = True
> > > krb5_store_password_if_offline = True
> > > ipa_domain = xyz.com
> > > id_provider = ipa
> > > auth_provider = ipa
> > > access_provider = ipa
> > > ldap_tls_cacert = /etc/ipa/ca.crt
> > > ipa_hostname = 10.65.16.4
> >
> > The ipa_hostname value is wrong. It's meant for systems where hostname
> > reports a different name that what is the name the host is registered as
> > in IPA. Including an IP address there doesn't make much sense.
> >
> > > chpass_provider = ipa
> > > ipa_server = ipa-master-in.xyz.com
> > > dns_discovery_domain = xyz.com
> > > ignore_group_members=True
> > > ldap_purge_cache_timeout = 0
> > > debug_level=8
> > > [sssd]
> > > services = nss, sudo, pam, ssh
> > > config_file_version = 2
> > >
> > > domains = xyz.com
> > > [nss]
> > > homedir_substring = /home
> > >
> > > [pam]
> > > pam_id_timeout = 3
> > >
> > > [sudo]
> > >
> > > [autofs]
> > >
> > > [ssh]
> > >
> > > [pac]
> > >
> > > [ifp]
> > >
> > >
> > >
> > > And here is the login times and logs
> > >
> > > [root@ipa-client-1 :~] date;ssh testuser@localhost
> > > Tue Jul 26 12:06:37 UTC 2016
> > > testuser@localhost's password:
> > > Last login: Tue Jul 26 12:03:53 2016 from 127.0.0.1
> > > [testuser@ipa-client-1 :~] date
> > > Tue Jul 26 12:06:55 UTC 2016
> > >
> > >
> > > sssd_domain logs
> > >
> > > (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_message_handler]
> > > (0x2000): Received SBUS method
> > > org.freedesktop.sssd.dataprovider.getAccountInfo on path
> > > /org/freedesktop/sssd/dataprovider
> > > (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [sbus_get_sender_id_send]
> > > (0x2000): Not a sysbus message, quit
> > > (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [be_get_account_info]
> > > (0x0200): Got request for [0x3][1][name=testuser]
> > > (Tue Jul 26 12:06:40 2016) [sssd[be[xyz.com]]] [be_req_set_domain]
> > > (0x0400): Changing request domain from [xyz.com] to [xyz.com]
> > > (Tue Jul 26 12:06:40 2016)