Bug 5468 - Creating and signing a hostcert with a non fully qualified hostname behaves odd
: Creating and signing a hostcert with a non fully qualified hostname behaves odd
Status: RESOLVED FIXED
: Simple CA
Simple CA
: unspecified
: Macintosh All
: P3 normal
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2007-08-01 11:44 by
Modified: 2008-08-11 15:51 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-08-01 11:44:57
(GT version: 4.0.5)

Creating a hostcert request for a non fully qualified hostname gives a
sentence that the hostname is not fully qualified but does not abort
regardless what i enter although it says that it's aborting.
So if one does not look closely everything looks fine.
Signing this hostcert request however fails.
(Signing a hostcert request with a FQDN hostname works fine).

I guess the correct behavior would be to really abort or to
give a stronger warning.

We ran into that on lucky0 of the lucky cluster in MCS.
The command hostname here returns only lucky0, so calling
"grid-cert-request -host `hostname`" as mentioned in the
Quickstart guide causes this problem.

Here's what happens, reproduced on my laptop:

Create the hostcert request:
############################

lappi2:/etc/grid-security root# grid-cert-request -host lappi2    
The hostname lappi2 does not appear to be fully qualified.
Do you wish to continue? [n] 
Aborting
Generating a 1024 bit RSA private key
...++++++
...................................................................................++++++
writing new private key to '/etc/grid-security/hostkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Level 0 Organization [Grid]:Level 0 Organizational Unit [GlobusTest]:Level 1
Organizational Unit [simpleCA-lappi2.local]:Name (e.g., John M. Smith) []:

A private host key and a certificate request has been generated
with the subject:

/O=Grid/OU=GlobusTest/OU=simpleCA-lappi2.local

----------------------------------------------------------

The private key is stored in /etc/grid-security/hostkey.pem
The request is stored in /etc/grid-security/hostcert_request.pem

Please e-mail the request to the Globus Simple CA feller@mcs.anl.gov
You may use a command similar to the following:

 cat /etc/grid-security/hostcert_request.pem | mail feller@mcs.anl.gov

Only use the above if this machine can send AND receive e-mail. if not, please
mail using some other method.

Your certificate will be mailed to you within two working days.
If you receive no response, contact Globus Simple CA at feller@mcs.anl.gov


Sign the hostcert request:
##########################

lappi2:~ martinfeller$ grid-ca-sign \
            -in /etc/grid-security/hostcert_request.pem \
            -out hostcert.pem

To sign the request
please enter the password for the CA key:

ERROR: Failed to find signed cert in CA cert store with subject:
       /O=Grid/OU=GlobusTest/OU=simpleCA-lappi2.local
------- Comment #1 From 2007-08-01 17:26:50 -------
But when you choose "y" for "continue?" it works right?  Works here.  I'm
seeing the same thing you do when I choose "n", it sounds like the only problem
here is that it should abort when "n" is chosen for continue.

This is clearly what is intended in the code but it is not happening because
the get_host_CN() function is running in a subshell so the call to "exit" there
will not do the intended thing.

Attachments are disabled so inlining...


----------------------------
This demonstrates the issue:
----------------------------

#!/bin/sh

function afunc() {
  echo "hello"
  exit 1
}

NOTEXITING=`afunc`
echo "reachable"
afunc
echo "unreachable"


---------------------
This fixes the issue:
---------------------

--- grid-cert-request.orig      2007-08-01 17:15:29.000000000 -0500
+++ grid-cert-request   2007-08-01 17:17:48.000000000 -0500
@@ -591,7 +591,7 @@

                 *)
                     ${GLOBUS_SH_ECHO-echo} "Aborting" 1>&2
-                    exit 1
+                    return 1
                     ;;
             esac
         fi
@@ -600,6 +600,7 @@
     fi

     echo ${_common_name}
+    return 0
 }


@@ -817,6 +818,9 @@
     COMMON_NAME="`get_user_CN`"
 else
     COMMON_NAME="`get_host_CN`"
+    if [ $? -ne 0 ]; then
+      exit 1
+    fi
 fi

 # do clean up on abort
------- Comment #2 From 2007-08-01 17:45:10 -------
(In reply to comment #1)
> But when you choose "y" for "continue?" it works right?  Works here.

That works for me too.
------- Comment #3 From 2007-08-01 20:08:06 -------
Tim: Your patch works fine for me.
Will/Can you commit it?
------- Comment #4 From 2007-08-01 20:34:29 -------
Committed to HEAD, but this may constitute an interface change in some people's
eyes with respect to globus_4_0_branch (even if it is a positive one).

For example someone may be running expect style wrappers around
grid-cert-request... ?
------- Comment #5 From 2007-08-01 21:39:36 -------
hm, if backwards compatibility means keeping bugs
then i would think it's too strict. Although this
is not a big bug here. So I don't mind, i guess
some people think more strict about BC than me.
------- Comment #6 From 2007-08-07 07:38:05 -------
I'd recommend sticking this in the 4.0 branch as well.
------- Comment #7 From 2007-08-07 11:33:26 -------
Commited to globus_4_0_branch as well