Re: Problems revoking a cert

[Michael Leone]

On Mon, Feb 24, 2020 at 12:09 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Michael Leone
> > Sent: Monday, February 24, 2020 09:37
>
> > SO I was an idiot, and signed a certificate, but specified an invalid
> location. i.e.,
> > I used a "/" instead of a "/" in the location.
>
> I assume that was supposed to be 'a "\" instead of a "/"', based on what
> you have below.
>

Yes, I had it backwards. And I was able to find the file, and properly
revoke it, after sending my initial email. I just haven't had time to go
back and tell the list.


>
> > $ sudo openssl ca -in requests/.req -out
> certs\-2020-02-24.
> >
> > And so I can't find that cert file anywhere (obviously).
>
> That's not obvious at all.


I meant - obviously it's not in the subdirectory I thought it would be in
...



> Does your CA configuration not have a new_certs_dir? Normally it will
> create a copy of the certificate there, under the serial number.
>
> > I know the serial number of the wrongly issued cert, I had hoped I could
> revoke
> > using just the serial number. But searches tell me I can't do it that
> way.
>
> Well, you *can*, by editing the CA's index.txt file directly. You can
> create and revoke a test certificate to see what the altered line should
> look like. (It will start with "R" instead of "V", and have a revocation
> date. Fields are separated by tabs.)
>

Interesting. Thanks.

Problems revoking a cert

[Michael Leone]

SO I was an idiot, and signed a certificate, but specified an invalid
location. i.e., I used a "/" instead of a "/" in the location.

$ sudo openssl ca -in requests/.req -out
certs\-2020-02-24.

And so I can't find that cert file anywhere (obviously). So I'd like to
revoke it, so that I can re-sign it properly. But whenever I go to revoke
it, I have nothing to use an input to the revoke functionality.

I know the serial number of the wrongly issued cert, I had hoped I could
revoke using just the serial number. But searches tell me I can't do it
that way.

So what can I do now? (short of asking for another request file, I mean - I
can't resign the existing one, openssl tells me that a cert already exists.
And I don't think I can just insert the bad cert serial number in the CRL,
right? To "effectively" revoke it, so I can resign, properly?).

Thanks
-- 

Mike. Leone, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

How to split a pfx file into cert and key?

[Michael Leone]

I received a pfx file from one our techs. A pfx file is a cert and key, all
in one binary file. He needs me to split it out into the cert and the key,
so I can create a new request from that key, and then sign a new cert for
him.

(no, I don't know why he can't just create a new request. And I would
revoke the old cert, except that I am unsure of the details he used in
naming it, so I don't know what to revoke .. So I am stuck trying to see if
I can help the guy, by creating a new request from the private key,
presuming I can extract the private key ...)

Anyways, I found this set of commands

Extracting Certificate and Private Key Files from a .pfx File

https://wiki.cac.washington.edu/display/infra/Extracting+Certificate+and+Private+Key+Files+from+a+.pfx+File



   1. Note: the *.pfx file is in PKCS#12 format and includes both the
   certificate and the private key.
   2. Run the following command to export the private key: openssl pkcs12
   -in certname.pfx -nocerts -out key.pem -nodes
   3. Run the following command to export the certificate: openssl pkcs12
   -in certname.pfx -nokeys -out cert.pem
   4. Run the following command to remove the passphrase from the private
   key: openssl rsa -in key.pem -out server.key


But I'm asked for an "Import password" ..

$ sudo openssl pkcs12 -in requests/DCTRNPS001_cert.pfx -nocerts -out
DCTRNPS001_key.pem -nodes
Enter Import Password:

And I have no idea what an "import" password is. It's not the password for
the private key, so I don't know what it is.

Pointers, anyone?

-- 

Mike. Leone, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 4:19 PM Michael Wojcik
 wrote:
>
> > From: Michael Leone [mailto:tur...@mike-leone.com]
> > Sent: Wednesday, February 12, 2020 12:35
>
> > Even though I used what might be the wrong terms, I'm sure you knew what I 
> > meant ...
>
> Sure. But PKIX, and X.509-based PKI more generally, are - not to mince words 
> - horrible. They're agonizingly complicated and confusing, and arguably 
> fundamentally broken in various respects. (See for example the issues raised 
> by the infamous "The OSI of a New Generation" presentation.)

I'm not sure how "infamous" it is, as I've never heard of it, even in
passing. :-)

> And here on the openssl-users list there are people with widely varying 
> experience with and understanding of these matters; and the list is archived 
> in various places, which means there's some chance someone will read these 
> notes years from now. Many of those people don't have the time to become 
> experts in PKI, and will want to be able to search for additional information 
> based on what they see here.

Yeah, that would be me. :-)

> So it's useful to try to be very precise in our terminology.

You're right, of course.
>
> Often, for example, the cognoscenti will refer to a certificate's "purpose". 
> That's an ambiguous term. In context it might refer to Basic Constraints, or 
> Key Usage, or Extended Key Usage, or even the old Netscape Cert Type; it 
> might refer to something inferred from other attributes (if Subject DN is the 
> same as Issuer DN, then it's self-signed and possibly a root); or it might 
> refer to something particular to its PKI or application, and not actually an 
> attribute of the certificate at all. That's fine when we all understand what 
> we're talking about. On the list, however, it's best to be explicit: "EKU 
> should include TSL Web Server Authentication for this type of certificate" 
> and so forth.
>
> For some readers, using "CA" and "certificate" interchangeably could be very 
> confusing.
>
> So I'm not being pedantic just for its own sake (I can yell at the television 
> for that). Apologies if it came across that way.

I get it. Sorry I snapped. No apologies needed on your side.

-- 

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

This space reserved for future witticisms ...

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 2:22 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Michael Leone
> > Sent: Wednesday, February 12, 2020 11:59
>
> > ... the only CA I have is the root, so that is what I will be signing
> with.
>
> This is incorrect. A CA is not a certificate. A CA is an organization or
> individual who controls one or more root certificates, and possibly one or
> more intermediate certificates.
>

Even though I used what might be the wrong terms, I'm sure you knew what I
meant ...

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 1:16 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> Terminological note: "Windows intermediate CA" isn't really a meaningful
> phrase. There's nothing OS-specific about a CA. What you're creating is a
> Windows-hosted implementation of your intermediate-CA functions. And,
> actually, what you're really creating is a Windows-hosted implementation of
> your CA's intermediate functions. (It's one CA, with one or more root
> signing certificates and one or more intermediate signing certificates,
> associated private keys, and other infrastructure such as
> issued-certificates database and CRL.)
>
> There's nothing preventing someone from taking a Windows-hosted CA and
> moving it to some other platform, or vice versa, assuming the
> infrastructure data can be converted appropriately.
>

Noted.


> I suppose it depends on what you mean by "differently". Intermediate
> signing certificates are not the same as entity certificates, so you have
> to do *something* to tell the CA implementation what you're doing.
>

"Differently" means issuing the signing command differently than I would
for any other requested cert. As in my example, I just do "sudo openssl ca
-in  -out ", and don't specify any other specific
configurations. And that works fine for webservers, domain controllers,
load balancers, etc. They request certain extensions, and that command
gives those requested extensions..

Differences include:
> - Intermediate certificates are signed by the root (unless you have
> multiple layers of intermediates; let's ignore that possibility). Entity
> certificates are signed by an intermediate.
>

I only have one root CA, so that's what I will be signing with.


> - Intermediate certificates will (should) have CA:TRUE in Basic
> Constraints; entity certificates will have CA:FALSE.
>

I imagine that will already be in the request from the Windows CA, although
I haven't created it yet, to verify that. The command to create the request
specifically asks if it is to be an intermediate CA, so I can't imagine
they would ask that unless it was to use a specific template for that type
of request. (yes, it is possible to choose which template the request uses,
and you could, at that point, add in anything you wanted it to ask for  -
basic constraints, etc).


> Here's the config section I use for my test intermediate certificate:
>
> [ v3_intermediate_ca ]
> authorityKeyIdentifier = keyid:always,issuer
> # pathlen:0 means these certs can only sign non-CA certs
> basicConstraints = critical, CA:true, pathlen:0
> keyUsage = critical, digitalSignature, cRLSign, keyCertSign
> nsComment = "TestCA Intermediate Certificate"
> subjectKeyIdentifier = hash
>

Yes, the openssl.cnf I have came with that section, too. But I don't see
how to use that section specifically, or when it's needed to use that
section.


> No, but you are generating and signing your intermediate CA certificate
> using OpenSSL, so that part of the process in the examples is likely
> relevant.
>


> Now, that said: Microsoft likes to put some extensions of its own in
> certificate requests. It's been some years since I messed around with
> Microsoft's certificate services, so I don't remember details; but it's
> possible those extensions might be relevant to how the Windows
> implementation of the CA intermediate-signing functions works. So you might
> want to use openssl to see what extensions are in the CSR created by
> Windows, and whether they're in the certificate your CA issues.
>

I do know how to show the details of requests, and signed certificates,
yes. And I will do that. I just wasn't sure of any differences in how to
sign an intermediate CA, as opposed to an end entity (I guess that's the
term - you know, a "regular" certificate, like something used by a web
server to secure traffic).

Thanks

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger  wrote:

> On 2/12/2020 11:32, Michael Leone wrote:
>
> So we are mostly a MS Windows shop. But I use a Linux openssl as my root
> CA. What I am planning on doing, is creating a Windows intermediate CA, and
> using that to sign all my internal requests. But before I do that, I have a
> couple of questions.
>
> I have the steps to install the certificate services in AD, and create an
> intermediate CA request. What I'm wondering is, do I sign that cert
> differently than any normal cert? I don't see why I would. I mean, the
> request should specify that it wants to be a CA, and so I should just be
> able to
>
> openssl ca -in  -out 
>
> and maybe the -extfile, to specify SANs.
>
> Am I correct in thinking that? I see many, many openssl examples, but
> they're all for creating an intermediate  CA using openssl, which I'm not
> doing. And the rest of the examples seem to be how to sign using the
> resulting intermediate CA cert itself, which again, is not what I will be
> doing .
>
> Any pointers appreciated. Thanks!
>
> You have to sign the intermediate with the root in order to maintain the
> chain of custody and certification.
>

Well, yes. Sorry if that wasn't clear. Yes, the only CA I have is the root,
so that is what I will be signing with. So what  I am asking, is the
signing command different for an intermediate CA than for a regular (I
guess the term is "End Entity") certificate?

(I already have the CA cert pushed out into the certificate stores of all
my domain members, so any new cert, issued by either the root or the
intermediate, will chain fully. (once I push out the intermediate cert to
all domain members).

Questions about signing an intermediate CA

[Michael Leone]

So we are mostly a MS Windows shop. But I use a Linux openssl as my root
CA. What I am planning on doing, is creating a Windows intermediate CA, and
using that to sign all my internal requests. But before I do that, I have a
couple of questions.

I have the steps to install the certificate services in AD, and create an
intermediate CA request. What I'm wondering is, do I sign that cert
differently than any normal cert? I don't see why I would. I mean, the
request should specify that it wants to be a CA, and so I should just be
able to

openssl ca -in  -out 

and maybe the -extfile, to specify SANs.

Am I correct in thinking that? I see many, many openssl examples, but
they're all for creating an intermediate  CA using openssl, which I'm not
doing. And the rest of the examples seem to be how to sign using the
resulting intermediate CA cert itself, which again, is not what I will be
doing .

Any pointers appreciated. Thanks!


-- 

Mike. Leone, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 4:02 PM Michael Wojcik
 wrote:
>
> > From: Michael Leone [mailto:tur...@mike-leone.com]
> > Sent: Friday, February 07, 2020 13:13
> >
> > I've got it almost all figured out, except how to get a subjectAltName
> > automatically populated by the CN of the requestor. My requests aren't
> > asking for a SAN, but Chrome isn't happy without one, so I'd like to
> > at least auto-populate 1 SAN by having it be the DNS: of the
> > requesting CSR.
>
>
> Not automatically, unfortunately. openssl ca recognizes a special 
> "email:copy" token in the extension list in the configuration file, but 
> that's only for email addresses in the Subject DN.

 Here's what I did. I created a file with a section name, and a SAN name:

$ sudo more cert-extensions
[ PHA_extensions ]
subjectAltName=DNS.1:

I then call that out, when I sign:

$ sudo openssl ca -days 3650 -in requests/request.CSR.txt -out
certs/2020-02-10.pem -extensions PHA_extensions -extfile
cert-extensions -policy policy_anything

That way, I can write up step-by-step HOWTOs, for the other folks in
the department to whom using the command line is an obsolete and
dinosaur way of computing (don't ask ..), and just tell them they have
to create a simple text file with the specific alt name(s) wanted, and
copy that, along with the CSR, over to the Linux VM for signing, and
issue the above command. following the HOWTO.

Eventually, I will be creating a Windows Intermediate CA, and that way
I can just generate the certs that way, which is a lot easier, in an
almost all Windows environment, using AD. And then I can turn off the
Linux root CA, since I'll never use it again; I'll only use the
intermediate CA.

Thanks for all the help, everybody. It never occurred to me that I
wasn't issuing certs the correct way, since the way I was issuing
them, had always worked. Right up until I needed a SAN or certain
extensions ...

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 3:08 PM Michael Wojcik
 wrote:
>
> > From: Michael Leone [mailto:tur...@mike-leone.com]
> > Sent: Friday, February 07, 2020 11:55
> >
> > How is that this works for everyone else, and not me? :-)
>
> It doesn't.
>
> I just reviewed this whole note stream, and realized you're using "openssl 
> req" to create the certificate, rather than "openssl ca", according to your 
> first note.
>
> openssl req doesn't respect copy_extensions, because it doesn't use a 
> CA-section in the configuration file.
>
> To accomplish what you want, you'll have to use openssl ca. There are a 
> number of walkthroughs online for setting that up.

Yep, I've been communicating offlist with another member, and he's
finally set me straight. Now I am using "openssl ca", and it is give
me the extensions the CSR is asking for.

I've got it almost all figured out, except how to get a subjectAltName
automatically populated by the CN of the requestor. My requests aren't
asking for a SAN, but Chrome isn't happy without one, so I'd like to
at least auto-populate 1 SAN by having it be the DNS: of the
requesting CSR.

Is that doable?

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 1:46 PM Michael Leone  wrote:
>
> On Fri, Feb 7, 2020 at 12:35 PM Michael Wojcik
>  wrote:
> > Or copied using the copy_extensions option, as noted in the discussion of 
> > that issue.
> >
> > In the OpenSSL configuration file used by "openssl ca", in the CA section 
> > (that is, the section named by the default_ca option, or in the section 
> > specified by the -name parameter to the openssl ca command), add:
> >
> > copy_extensions=copy
> >
> > That will copy all extensions from the CSR that aren't overridden by the 
> > specified extensions section. As Rich noted in the discussion of issue 
> > 10458, and as should be obvious, this is a major security risk if you don't 
> > also control CSR generation (i.e. if your CSRs are tainted).
>
> I will try that. Since I deal only in cert requests generated

Nope; didn't work for me. I get no extensions listed in the cert at
all, not the ones requested by the CSR, not the ones listed in the CA.
Nuthin. LOL

Only if I use the -extfile parameter do I get extensions, and those
may not be what the CSR is requesting.

How is that this works for everyone else, and not me? :-)

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 12:35 PM Michael Wojcik
 wrote:
> Or copied using the copy_extensions option, as noted in the discussion of 
> that issue.
>
> In the OpenSSL configuration file used by "openssl ca", in the CA section 
> (that is, the section named by the default_ca option, or in the section 
> specified by the -name parameter to the openssl ca command), add:
>
> copy_extensions=copy
>
> That will copy all extensions from the CSR that aren't overridden by the 
> specified extensions section. As Rich noted in the discussion of issue 10458, 
> and as should be obvious, this is a major security risk if you don't also 
> control CSR generation (i.e. if your CSRs are tainted).

I will try that. Since I deal only in cert requests generated
in-house, this should be OK for us.

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 11:02 AM Sergio NNX  wrote:
>
> This is the basics of OpenSSL!
>
> You would like to add extensions to a CSR or the problem arises when signing 
> it?

Yes, when I sign, I get no extensions that are requested in the CSR.
Nor are any added, when I sign (requested or not).

> > OK, so I read "man 5 x509v3_config", and it's still not clear to me how I 
> > get my extensions added to a req.
> Which part is not clear?

Pretty much all of it :-), because I tried doing it the way the man
page showed, and nothing worked for me.
I want the signed cert to have the requested extensions. And also a
SAN, since Chrome isn't happy unless it finds a SAN.
And sometimes more extensions than requested, if need be.

> First, you create a CSR file with the extensions you need/want.
> (openssl req -new -config user.cnf -key user.key -out user.csr)

No, our CSRs are created by the machine that will use it. (IIS server,
AD DC, Linux phone system, etc). I never create a req, I just sign
incoming ones.

> That's it.

I can sign just fine. What I can't get it is a cert the way I need it
to be ... (well, I can, if I add in a -extfile containing all the
extensions, requested or not).

I can send you the openssl.cnf off list.

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 10:30 AM Michael Richardson  wrote:
>
>
> Michael Leone  wrote:
> > On Fri, Feb 7, 2020 at 8:54 AM Michael Leone  
> wrote:
> >> Thanks, tho, I did learn a thing or two. I see from this example
> >>
> >> openssl req -config $cfgdir/openssl-root.cnf $passin \
> >> -set_serial 0x$(openssl rand -hex $sn)\
> >> -keyform $format -outform $format\
> >> -key $rootca/private/ca.key.$format -subj "$DN"\
> >> -new -x509 -days 7300 -sha256 -extensions v3_ca\
> >> -out $cadir/certs/ca.cert.$format
> >>
> >>
> >> That maybe I can pass the explicit section that has the extensions
> >> that I want, from the command line. I will try that. In my case, the
> >> "[ usr_cert ]" or perhaps "[ server_cert ]".
>
> > Nope, no key extensions in the generated cert, even when passing
> > "-extensions user_cert" on the CLI.
>
> > I'll keep plugging away, I guess.
>
> What's in the [user_cert] stanza?

This: (the "user" is a typo; the entry reads "usr", and that is what I
used in the CLI invocation.

# Extensions for client certificates (`man x509v3_config`).
[ usr_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "PHA Internally generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage=digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names

I did get it to work, on the signing command by doing this:

sudo openssl x509 -req -days 3650 -in requests/ -CA
certs/ -CAkey private/ -extensions PHA_extensions -extfile
cert-extensions

with the file "cert-extensions":

[ PHA_extensions ]
basicConstraints = critical,CA:FALSE
keyUsage=digitalSignature,keyEncipherment,dataEncipherment,nonRepudiation
extendedKeyUsage=serverAuth,clientAuth
subjectKeyIdentifier=hash
subjectAltName=DNS.1:

I couldn't get any extensions - none, or SAN, into the cert any other
way. Nor did the cert have the CSR requested extensions, until I added
them in that file. This is in the CSR:

   Requested Extensions:
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment,
Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication

(I am using a IIS server to make the requests, as the vast majority of
certs that I will sign will come either from IIS, or a Windows server)

-- 

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

This space reserved for future witticisms ...

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Thu, Feb 6, 2020 at 5:45 PM Viktor Dukhovni
 wrote:
>
> On Thu, Feb 06, 2020 at 02:36:03PM -0500, Michael Leone wrote:
>
> > Oh, I can add extensions by signing and using the -extfile option, and
> > specifying a file with the specific options I want to give the
> > certificate. But I don't want to have to use an addon file, I want to
> > add parameters to all signed certificates.
>
> The documentation of x509(1) which you're using with "-req" as a
> mini-CA, states explicitly:
>
>-extfile filename
>File containing certificate extensions to use. If not specified
>then no extensions are added to the certificate.
>
>-extensions section
>The section to add certificate extensions from. If this option is
>not specified then the extensions should either be contained in the
>unnamed (default) section or the default section should contain a
>variable called "extensions" which contains the section to use. See
>the x509v3_config(5) manual page for details of the extension
>section format.

OK, so I read "man 5 x509v3_config", and it's still not clear to me
how I get my extensions added to a req.
I am following thsi example page from RedHat

 https://access.redhat.com/solutions/28965

So what is the secret I am missing? The way I am reading it, in the "[
req ]", section I need to add

x509_extensions  = usr_cert # Desired extensions section

and in "[ usr_cert ]", I have added the "KeyUsage" and
"ExtendedKeyUsage" values I want.

which I have done, and which is not giving me what I want.

Obviously I'm missing something basic. Can anyone point out what I am
doing wrong?

The example page shows signing using a separate extensions file, which
I can do, and have done, and that gives me those extensions. But why
doesn't it work without that extension file??

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Fri, Feb 7, 2020 at 8:54 AM Michael Leone  wrote:
> Thanks, tho, I did learn a thing or two. I see from this example
>
> openssl req -config $cfgdir/openssl-root.cnf $passin \
>  -set_serial 0x$(openssl rand -hex $sn)\
>  -keyform $format -outform $format\
>  -key $rootca/private/ca.key.$format -subj "$DN"\
>  -new -x509 -days 7300 -sha256 -extensions v3_ca\
>  -out $cadir/certs/ca.cert.$format
>
>
> That maybe I can pass the explicit section that has the extensions
> that I want, from the command line. I will try that. In my case, the
> "[ usr_cert ]" or perhaps "[ server_cert ]".

Nope, no key extensions in the generated cert, even when passing
"-extensions user_cert" on the CLI.

I'll keep plugging away, I guess.

Re: Problems adding specific extensions to signed certificates

[Michael Leone]

On Thu, Feb 6, 2020 at 5:45 PM Viktor Dukhovni 
wrote:

> On Thu, Feb 06, 2020 at 02:36:03PM -0500, Michael Leone wrote:
>
> > Oh, I can add extensions by signing and using the -extfile option, and
> > specifying a file with the specific options I want to give the
> > certificate. But I don't want to have to use an addon file, I want to
> > add parameters to all signed certificates.
>
> The documentation of x509(1) which you're using with "-req" as a
> mini-CA, states explicitly:
>
>-extfile filename
>File containing certificate extensions to use. If not specified
>then no extensions are added to the certificate.
>
>-extensions section
>The section to add certificate extensions from. If this option
> is
>not specified then the extensions should either be contained in
> the
>unnamed (default) section or the default section should contain
> a
>variable called "extensions" which contains the section to use.
> See
>the x509v3_config(5) manual page for details of the extension
>section format.
>
>
Ok. I'm not really a Linux guy, but I guess that means to do a "man 5
x509v3_config"?

I'll check when I get to work. I guess I just have a section mislabeled, or
I need to call a section differently?



> However, you don't need to create any static .cnf files with the desired
> settings.  You can specify a "-extfile" on the fly via bash(1) inline
> files:
>
> openssl x509 -extfile <(printf "..." ) ...
>
> which is the approach taken in:
>
> https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh



As I said, not really a Linux guy. More, I need to write this as a HOWTO
for the others in my department, who have little (well, no) Linux
experience. I can tell them what changes to make to a text file, and how to
scp it to the Linux box, and then a step-by-step how to sign a cert using
said file, and then scp it back to where it needs to be (we're a Windows
place, with rare exceptions).

I'll look into it tomorrow at work. If I have further issues, I'll be back.
:-)

Thanks for the help.

Problems adding specific extensions to signed certificates

[Michael Leone]

This is driving me crazy. I have a CA, running on Debian 9, running
openssl 1.1.0. (this CA is for our organization internal use only, of
course). I can successfully sign requests. However, what I can't seem
to do, is add x509 extensions to the signed certificate, as part of
the openssl.cnf.

Oh, I can add extensions by signing and using the -extfile option, and
specifying a file with the specific options I want to give the
certificate. But I don't want to have to use an addon file, I want to
add parameters to all signed certificates.

keyUsage=digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectKeyIdentifier=hash

(since all requests come from our own servers, I know that I want to
be sure that the requesting cert gets these, regardless of what else
the request asks for)

But I'm having a heck of a time accomplishing this, probably due to my
own lack of understanding. I thought that, in the "[ req ]" section of
my openssl.cnf, if I have this:


# This is the default certificate request settings
#
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
#x509_extensions = v3_ca # The extensions to add to the self signed cert
req_extensions = v3_req
x509_extensions = usr_cert

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "PHA Internally generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
#keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
#extendedKeyUsage = clientAuth, emailProtection
#
# PHA Added
#
keyUsage=digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
subjectKeyIdentifier=hash

Then I would get the extensions that I want, since they are in the "[
usr_cert ]" section, which is what is called for the x509_extensions
when signing a request.

But that turns out not to be the case.

What part am I missing, or not understanding? I've got something basic
wrong here, I just can't figure out what.

Signing command:

sudo openssl x509 -req -days 3650 -in requests/ -CA
certs/ -CAkey private/ -CAserial
serial  -out certs/

Doing that, I get no extensions.
Adding " -extfile cert-extensions", and putting the above extensions
in that file, then I *do* get them.

I can post the whole openssl.cnf, if need be.

Thanks for any help.

-- 

Mike. Leone, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...