Created attachment 614881 [details]
Content of /var/log/pki-ca

In the past this error has suggested a DNS issue. Since you're configuring DNS with IPA we have a bit of a chicken and egg problem.

What does /etc/hosts look like? Does it have both the IPv4 and IPv6 address in it?

I have rerun ipa-server-install without --setup-dns, and the result is the same.

# cat /etc/hosts:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Thus, fi.lan is not in there.  Still, it can be resolved by ping and wget, but not by sslget.

# ping -c 1 fi.lan
PING fi.lan (192.168.100.30) 56(84) bytes of data.
64 bytes from fi.lan (192.168.100.30): icmp_req=1 ttl=64 time=0.066 ms

There is this line in /etc/nsswitch.conf:

# grep ^hosts /etc/nsswitch.conf
hosts:      files dns myhostname

The "myhostname" entry is responsible for resolving fi.lan to 192.168.100.30, as I have learned just now.

Adding fi.lan to /etc/hosts doesn't help, sslget still fails:

# grep fi /etc/hosts
192.168.100.30: fi fi.lan
# /usr/bin/sslget -v -n ipa-ca-agent -p $password -d /tmp/tmp-xZ2bD4 -r /ca/agent/ca/profileReview?requestId=7 fi.lan:9443 >/dev/null
GET /ca/agent/ca/profileReview?requestId=7 HTTP/1.0

port: 9443
addr='fi.lan'
family='10'
exit after PR_Connect with error -5987:

Using the IP address directly makes sslget work:

# /usr/bin/sslget -v -n ipa-ca-agent -p $password -d /tmp/tmp-xZ2bD4 -r /ca/agent/ca/profileReview?requestId=7 192.168.100.30:9443 >/dev/null
GET /ca/agent/ca/profileReview?requestId=7 HTTP/1.0

port: 9443
addr='192.168.100.30'
family='2'
Called mygetclientauthdata - nickname = ipa-ca-agent
   mygetclientauthdata - cert = 1ded5b0
   mygetclientauthdata - privkey = 1e30770
PR_Write wrote 55 bytes from bigBuf
bytes: [GET /ca/agent/ca/profileReview?requestId=7 HTTP/1.0

]
do_writes shutting down send socket
do_writes exiting with (failure = 0)
connection 1 read 9000 bytes (9000 total).
these bytes read:
connection 1 read 9000 bytes (18000 total).
these bytes read:
connection 1 read 9000 bytes (27000 total).
these bytes read:
connection 1 read 3364 bytes (30364 total).
these bytes read:
connection 1 read 30364 bytes total. -----------------------------



Thus, sslget doesn't seem to use nsswitch for resolving hostnames.  That seems to be the bug here.

Re-assigning package to dogtag, it provides sslget.

The same issue is reproduced again in bug 953464 in Fedora 19. We need to get this fixed.

Upstream ticket:
https://fedorahosted.org/pki/ticket/587

The following links may be beneficial:

    * https://developer.mozilla.org/en-US/docs/NSPR_API_Reference (NSPR docs)
    * https://bugzilla.mozilla.org/query.cgi (NSPR bugs)
    * http://mxr.mozilla.org/nspr/ (online NSPR src viewer)
    * http://0pointer.de/lennart/projects/nss-myhostname/ (nsswitch.conf myhostname)

In looking at the Description of Bugzilla Bug #859043, the error code
returned by 'sslget' is 6 which corresponds to this call:

   prStatus = PR_Connect(tcp_sock, addr, PR_SecondsToInterval(3));

In looking at the feedback of Bugzilla Bug #859043 in Comment #3, we noticed the following:

   The '/etc/hosts' was re-configured to look like this:  

        127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
        ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
        192.168.100.30: fi fi.lan
   In the documented failure case, it was noticed that family=10 (which appears
   to be PR_AF_INET6 which is associated with IPv6 addresses), even though
   the IP address (192.168.100.30) as placed into the /etc/hosts file is an IPv4
   address.

   The error returned appears to be this one documented in
   '/usr/include/nspr4/prerr.h':

       /* Invalid function argument */
       #define PR_INVALID_ARGUMENT_ERROR                (-5987L)

   The only parameter in PR_Connect() that appears to be questionable is the 'addr'
   passed-in as the second argument, especially as it appears to have a mis-match
   between the IPv4 address and the IPv6 family.

   It would be helpful to know the output of 'ifconfig' and the contents of the
   following files:

       * /etc/nsswitch.conf (if different from 'hosts: files dns myhostname')
       * /etc/hosts (if different from above)
       * /etc/resolv.conf
       * /etc/networks
       * /etc/sysconfig/network
       * /etc/sysconfig/network-scripts/ifcfg-<interfaces output by 'ifconfig'>

    In the meantime, we will try to replicate this condition on one of our local machines.

(In reply to comment #7)
> The following links may be beneficial:
> 
>     * https://developer.mozilla.org/en-US/docs/NSPR_API_Reference (NSPR docs)
>     * https://bugzilla.mozilla.org/query.cgi (NSPR bugs)
>     * http://mxr.mozilla.org/nspr/ (online NSPR src viewer)
>     * http://0pointer.de/lennart/projects/nss-myhostname/ (nsswitch.conf
> myhostname)
> 
> In looking at the Description of Bugzilla Bug #859043, the error code
> returned by 'sslget' is 6 which corresponds to this call:
> 
>    prStatus = PR_Connect(tcp_sock, addr, PR_SecondsToInterval(3));
> 
> In looking at the feedback of Bugzilla Bug #859043 in Comment #3, we noticed
> the following:
> 
>    The '/etc/hosts' was re-configured to look like this:  
> 
>         127.0.0.1 localhost localhost.localdomain localhost4
> localhost4.localdomain4
>         ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
>         192.168.100.30: fi fi.lan
>    In the documented failure case, it was noticed that family=10 (which
> appears
>    to be PR_AF_INET6 which is associated with IPv6 addresses), even though
>    the IP address (192.168.100.30) as placed into the /etc/hosts file is an
> IPv4
>    address.
> 
>    The error returned appears to be this one documented in
>    '/usr/include/nspr4/prerr.h':
> 
>        /* Invalid function argument */
>        #define PR_INVALID_ARGUMENT_ERROR                (-5987L)
> 
>    The only parameter in PR_Connect() that appears to be questionable is the
> 'addr'
>    passed-in as the second argument, especially as it appears to have a
> mis-match
>    between the IPv4 address and the IPv6 family.
> 
>    It would be helpful to know the output of 'ifconfig' and the contents of
> the
>    following files:
> 
>        * /etc/nsswitch.conf (if different from 'hosts: files dns myhostname')
>        * /etc/hosts (if different from above)
         * /etc/hostname
>        * /etc/resolv.conf
>        * /etc/networks
>        * /etc/sysconfig/network
>        * /etc/sysconfig/network-scripts/ifcfg-<interfaces output by
> 'ifconfig'>
> 
>     In the meantime, we will try to replicate this condition on one of our
> local machines.

>    It would be helpful to know the output of 'ifconfig' and the contents of
> the
>    following files:

I think this should be investigated on the Fedora 19 box where Alexander has seen the issue.  The virtual machine where I have first seen this doesn't exist anymore.

If I see this issue again, I'll provide the requested information.

Created attachment 740185 [details]
Fix sslget to skip link local addresses

(In reply to comment #10)
> Created attachment 740185 [details]
> Fix sslget to skip link local addresses

ACKed patch was committed to pki master:
* commit 7ca438db07efb122bc93efd0471be7a2be34b663

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.