More certificate confusion - issuing CA server config
Michael Leone
my shny new sha256, 4096 bit cert. w00t! LOL
So now, following (I think) best practices for cert issuance in an AD
environment, I want to make a new sub-CA (I think the term is
"intermediate CA") in my AD, to actually issue the certs to the other
member servers (web servers, devices, etc).
(I want the 2 tier model, an offline root CA (the Linux VM) and a
domain joined Windows 2016 server to be the Issuing CA for my domain.
So far, I've been a single tier, issuing certs from the old Linux root
CA. But I suppose I should go for an Enterprise style PKI, hence the 2
tier approach)
So in reading the old Best Practices guide
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc787550(v%3dws.10)
it tells me " the user who installs an enterprise CA must be a member
of the Active Directory Root Domain Admins and Enterprise Admins
security group". OK.
Now in my situation, I have a parent/child domain structure (this was
supposedly Best Practices many eons ago, when they first created this
AD). So does this mean I need to create this server in the *parent*
domain, so that the whole forest knows about this issuing CA? Using an
account in the Enterprise Admins group there?
Or can I create it in the child domain, where all the actual users and
member servers are?
All the examples are (understandably) for the simple single domain structure.
Sorry if I'mm being dense here, but I am trying, and researching,
before posting.
And if anyone has a better, more modern guide for doing this, one that
doesn't talk about copying the root CA from a FLOPPY (LOL), I'd
appreciate it.
--
Michael J. 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>
Just backpacking through the Uncanny Valley ....
Michael Leone
> So in reading the old Best Practices guide
> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc787550(v%3dws.10)
>
> it tells me " the user who installs an enterprise CA must be a member
> of the Active Directory Root Domain Admins and Enterprise Admins
> security group". OK.
>
> Now in my situation, I have a parent/child domain structure (this was
> supposedly Best Practices many eons ago, when they first created this
> AD). So does this mean I need to create this server in the *parent*
> domain, so that the whole forest knows about this issuing CA? Using an
> account in the Enterprise Admins group there?
>
> Or can I create it in the child domain, where all the actual users and
> member servers are?
for creating a Win 2016 issuing CA:
INSTALLING A TWO TIER PKI HIERARCHY IN WINDOWS SERVER 2016
https://myitworld.azurewebsites.net/2016/01/21/installing-two-tier-pki-hierarchy-windows-server-2016-part2/
Still have some questions, specifically about this CRL part, since my
root CA isn't a Windows server ...
Michael B. Smith
To write to the configNC requires EA perms.
Thanks.
Regards,
Michael B.
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To post to this group, send email to ntsys...@googlegroups.com.
Visit this group at https://groups.google.com/group/ntsysadmin.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BiHvGWsZsJa5XD5iL0jprHZWtMqOmVexd%3DUUnaF7%3Ds2eQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Michael B. Smith
Michael Leone
>
> A CA is always a forest level object (specifically PKI information is stored in the Configuration Naming Context of the forest). But it can reside in any domain in a forest.
install on it there? Using what credentials?
> To write to the configNC requires EA perms.
services on the issuing server as a user in the parent domain?
I'm missing something basic here ....
Dennis Pinckard
Honestly, I've only ever worked with CA's in a flat domain, although I did set up a lab child domain with its own 2-tier CA a year or so ago.
Intermediate CA's are generally found in 3 or more tiers. They
aren't the root and don't issue certs to end points. Often they
may be policy CA's or just used to manage a large tree of CA's.
That's my understanding of the terms, though.
I don't think it matters "where" you install the Issuing CA, so long as all accounts that will enroll certificates can be authenticated by the CA. Remember, you can have multiple CA's. Nothing says you can't have one in each domain, so long as they are trusted by all relevant end points.
For your CRL, even the root CA needs to republish it. In the Windows CA world, you would have defined an "lifespan" for the CRL. Normally, I would define a 1-year lifespan and power on my root CA every 6 months to republish. In an ideal world, you will never revoke a cert from your root. It should only ever issue CA certs for the sub-CA's and those never go away, get corrupt, get hacked, etc, right?
Your root ca should also have defined the location of its CRL.
You did use just "http" right? When you publish the root CRL,
you'll need to copy it over to the web server (or other CRL
distribution point). I generally create a
"http://pki.public.domain/CRL" website and put all of my CRL's
there.
Just use an account with Domain Admin & Enterprise Admin permissions to install the Issuing CA.
Word of advice. Test, test, test! Test your root CA and
validate the certs it issues are exactly the way you want them
BEFORE you install your sub-CAs. Make sure the CRL and AIA point
to the correct addresses. Make sure all devices that will trust
your certs can accept your Root CA cert. (I've had issues in the
past with some devices, specifically Cisco, not able to accept any
certs over 2048 bits). If anything fails, tear it down and try
again. Test publishing and replication of your CRL. You can
publish as often as you wish, so don't worry about it, but you
_must_ republish before it expires.
When you are satisfied with your Root CA, install your sub-CA,
but DON'T allow anyone to enroll certs. Ideally, don't add any
templates yet. Create a test template that only you can manually
enroll against. Issue a cert and validate that it is EXACTLY the
way you want. If it doesn't look right, tear it down and
reinstall just that CA. Just be sure to clean up any certs/CA
records that may get published to AD.
CA's aren't really that hard, but there is a learning curve, so take the time and get it right. Once they are in operation, many of the important settings CANNOT be changed.
Michael Leone
>
> To write to the configNC requires EA perms.
specify the EA credentials, so I would use <parentDomain>\<EA-member>.
Yes?
There's a lot of info on setting up CRL and CDP information. Is all
that really necessary, for my situation, or can I just get the request
from the Issuing CA; sign it using my Root CA; install the newly
signed cert back into the Issuing CA?
Michael B. Smith
I have a user named "user1" in domain b.c. user1 must be a member of EAs and DAs.
You need to publish a CRL from your root and from your issuing CA. A CDP (CRL Distribution Point) is simply where you publish that CRL. Without a valid CRL or an available OCSP, a certificate can't be fully validated.
Thanks.
Regards,
Michael B.
-----Original Message-----
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com] On Behalf Of Michael Leone
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To post to this group, send email to ntsys...@googlegroups.com.
Visit this group at https://groups.google.com/group/ntsysadmin.
Michael Leone
<ntsys...@doomsdaypig.com> wrote:
> For your CRL, even the root CA needs to republish it. In the Windows CA world, you would have defined an "lifespan" for the CRL. Normally, I would define a 1-year lifespan and power on my root CA every 6 months to republish. In an ideal world, you will never revoke a cert from your root. It should only ever issue CA certs for the sub-CA's and those never go away, get corrupt, get hacked, etc, right?
> Your root ca should also have defined the location of its CRL. You did use just "http" right?
>When you publish the root CRL, you'll need to copy it over to the web server (or other CRL distribution point). I generally create a "http://pki.public.domain/CRL" website and put all of my CRL's there.
that way (named "CRL or whatever), and the files copied there. I can
make a website using IIS on the Issuing server, I guess.
But I haven't generated any CRLs ... (yet) ...
> Just use an account with Domain Admin & Enterprise Admin permissions to install the Issuing CA.
only in the parent domain. They are Domain Admins and Enterprise
Admins up in there, but none of those accounts are Domain Admins in
the *child* domain.
Should they be?
> Word of advice. Test, test, test! Test your root CA and validate the certs it issues are exactly the way you want them BEFORE you install your sub-CAs.
be (I did a "openssl x509 -noout -text -in certs/<test-cert>.pem) and
it looked OK to me, said it was
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
(which I have as the default in openssl.cnf). That should be a typical
web server type cert.
>Make sure the CRL and AIA point to the correct addresses.
It's just the website that will host the CRL? And create one by just
"openssl ca gencrl", right?
>Make sure all devices that will trust your certs can accept your Root CA cert. (I've had issues in the past with some devices, specifically Cisco, not able to accept any certs over 2048 bits).
length, so it should have used the default of 2048. Although I am not
sure how to tell ...
> If anything fails, tear it down and try again. Test publishing and replication of your CRL. You can publish as often as you wish, so don't worry about it, but you _must_ republish before it expires.
>
> When you are satisfied with your Root CA, install your sub-CA, but DON'T allow anyone to enroll certs. Ideally, don't add any templates yet. Create a test template that only you can manually enroll against. Issue a cert and validate that it is EXACTLY the way you want. If it doesn't look right, tear it down and reinstall just that CA. Just be sure to clean up any certs/CA records that may get published to AD.
>
> CA's aren't really that hard, but there is a learning curve, so take the time and get it right. Once they are in operation, many of the important settings CANNOT be changed.
continuing on with a single tier PKI, and issuing certs from the Linux
box, the way I have been doing ...
No, seriously, thanks for all the help so far.
Michael Leone
>
> My parent domain is a.c. My child domain is b.c.
>
> I have a user named "user1" in domain b.c. user1 must be a member of EAs and DAs.
"b.c\user1" as a member of EA and DA?
My "user1" is already a member of DAs in the child b.c domain.
> You need to publish a CRL from your root and from your issuing CA. A CDP (CRL Distribution Point) is simply where you publish that CRL. Without a valid CRL or an available OCSP, a certificate can't be fully validated.
for my root CA ..
Michael B. Smith
>> "b.c\user1" as a member of EA and DA?
As Don pointed out, for the root you should only use an http CDP since it will be offline.
Michael Leone
>
> >> OK ... So you're saying that in a.c (the parent domain) you have
> >> "b.c\user1" as a member of EA and DA?
>
> Yes.
try to add a child domain user (I created one called "CertAdmin") to
DA in the parent, I can't check the name, as the child domain isn't
listed as a source.
(because DA is a Global group, meaning it only allows users from the
current domain?)
And since I can't check the name, I can't add it ...
For EA, I *can* add the user in the child domain to EA (and I did).
Or did you mean that the child domain acct had to be a DA in the child
domain, and EA in the parent (but *not* DA in the parent)?
That somehow doesn't seem right to me (not being DA in parent, not the
part about being in DA in the child)
Dennis Pinckard
Unfortunately, you've made a decision to not use Windows as your root CA. Nothing wrong with that, I've thought about doing it myself, but as this is the NTsysadmin list, you're going to find more Windows advice than Linux, I'd bet. But let's see what we can do.
You should be able to take your Root CA's public key, copy it to
your Windows workstation and double click on it. If it's in the
correct format, it will open the standard certificate dialog. It
will show the info you need to verify: key length, algorithm, etc.
It's been a while since I set up a root CA, so my memory was
foggy. Since it's a root, you trust that explicitly. As it is
self-signed, there is not CRL. Also, since it is a root
certificate, there the Authority Information Access (AIA) is not
embedded as that tells endpoints where to get the parent certs.
It's confusing, I know. With a Windows CA, you can open the MMC
and view all of the configuration easily.
I would expect that you would still define the CDP and AIA when installing the root CA. That information will be embedded in any certificates (other than the root cert) that are issued by the CA.
Out of curiosity, what distribution and certificate server are you using?
I generally try to map out a website to hold my CA related information. It will always use 'http' only. I normally do not have it running on my CA, but it can. It always uses a host header that is different than the host's name. Often I will have it in my DMZ so certificate information can be accessed internally or externally. With the host header, you can have a farm of web servers as large as you need, just be sure they are all up to date with cert chains and crl's.
A quick search for openssl.cnf yielded https://pki-tutorial.readthedocs.io/en/latest/expert/component-ca.conf.html It looks like they do it in a round-about way, but yes, I believe your [crl_info] will define "URI.0" as your CDP web address.
Everything you are learning and implementing applies if you do a single-tier or a multi-tier PKI. A multi-tier adds a little bit of complexity, but can make things much easier and more efficient in the long run. For example: create an offline root ca with an issuing CA in your production domain that issues just computer certs and a CA for issuing user certs. Now create an issuing CA in your domain that issues smartcard (PIV) certs. Create a 4rd CA to issue manual certs for network gear/IoT/etc. Each of these can be managed by a separate department. All of these CA's and their certs would be trusted because of the one root cert. Granted this is not a real-world example and I would add policy servers into that mix.
Michael Leone
<ntsys...@doomsdaypig.com> wrote:
>
> Unfortunately, you've made a decision to not use Windows as your root CA. Nothing wrong with that, I've thought about doing it myself, but as this is the NTsysadmin list, you're going to find more Windows advice than Linux, I'd bet. But let's see what we can do.
disconnected state, that I can play, and continually rebuild, if/when
I screw it up. The Linux root CA is a lot easier, since I don't have
to tear anything out of AD, if I need to remake the root CA (and I
have - 3 times now) ...
Also, I wanted to see how much I remembered about doing Linux ... LOL
> You should be able to take your Root CA's public key, copy it to your Windows workstation and double click on it. If it's in the correct format, it will open the standard certificate dialog. It will show the info you need to verify: key length, algorithm, etc.
openssl rsa -text -noout -in <private key file>
and it spits the number back to you (along with a bunch of other ... stuff).
> It's been a while since I set up a root CA, so my memory was foggy. Since it's a root, you trust that explicitly. As it is self-signed, there is not CRL. Also, since it is a root certificate, there the Authority Information Access (AIA) is not embedded as that tells endpoints where to get the parent certs. It's confusing, I know. With a Windows CA, you can open the MMC and view all of the configuration easily.
> I would expect that you would still define the CDP and AIA when installing the root CA. That information will be embedded in any certificates (other than the root cert) that are issued by the CA.
> Out of curiosity, what distribution and certificate server are you using?
> I generally try to map out a website to hold my CA related information. It will always use 'http' only. I normally do not have it running on my CA, but it can.
CA. If all it is is a regular IIS website with a name I specified
(such as http://<FQDN>/crl), that's easy enough. I already specified
the name I will give to my new issuing server.
Not planning on doing things this web certificate enrollment or
anything. Just need a few certs. Honestly, probably less than a dozen,
total.
> It always uses a host header that is different than the host's name. Often I will have it in my DMZ so certificate information can be accessed internally or externally. With the host header, you can have a farm of web servers as large as you need, just be sure they are all up to date with cert chains and crl's.
>
> A quick search for openssl.cnf yielded https://pki-tutorial.readthedocs.io/en/latest/expert/component-ca.conf.html It looks like they do it in a round-about way, but yes, I believe your [crl_info] will define "URI.0" as your CDP web address.
issuing CA server. I think I did it right. If not, I can still blow
away the cert and crl, and re-generate it.
> Everything you are learning and implementing applies if you do a single-tier or a multi-tier PKI. A multi-tier adds a little bit of complexity, but can make things much easier and more efficient in the long run. For example: create an offline root ca with an issuing CA in your production domain that issues just computer certs and a CA for issuing user certs.
certs (wireless controller).
Dennis Pinckard
Root CA's are the easiest until you import its cert into AD. Even then it's not difficult to get rid of.
I really want to stress to not tie your CDP/AIA to an actual hostname.
In DNS create an A record and point it to your IIS server IP address. I prefer the A record over CNAME, but you could use that as well. Call it "pki.ad.domainname" with your values for "ad.domainname"
In your IIS, create a new website pointing to an empty folder. On that website, click "Edit Bindings". Create a new binding for "http" and the DNS name you just created, "pki.ad.domainname". Remove any other bindings that may be on THAT website.
Create a "hello world" web page on that site.
Once DNS replicates, open a web browser to "http://pki.ad.domainname/helloworld.htm" and you should get the web page.
You've just set up a web page with a host header. That website will only respond on that hostname, not the actual hostname of the machine. This will allow one machine to host many webpages.
To load balance/HA, create a 2nd A record, "pki.ad.domainname",
pointing to a 2nd IIS host IP address. Replicate the steps
above. Now DNS will round robin the hosts: host A, then host B,
then host a again, etc.
Quick search:
https://knowledge.digicert.com/solution/SO20113.html
(Just ignore the parts about SSL, they are not needed for your PKI
website)
Michael Leone
Root CA's are the easiest until you import its cert into AD. Even then it's not difficult to get rid of.
I really want to stress to not tie your CDP/AIA to an actual hostname.
Michael B. Smith
Name your CDP/AIA something like pki.<domain>. If you name it pki.<host>.<domain> then you have to retain that host “forever”. (Yes, there are ways around this, but why complicate life?)
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Michael Leone
Sent: Thursday, June 20, 2019 3:18 PM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Re: More certificate confusion - issuing CA server config
On Tue, Jun 18, 2019 at 4:03 PM Dennis Pinckard <ntsys...@doomsdaypig.com> wrote:
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntsysadmin+...@googlegroups.com.
To post to this group, send email to
ntsys...@googlegroups.com.
Visit this group at https://groups.google.com/group/ntsysadmin.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BiNH7%3DjbFzU7EVnbyOMVWjjb5R%2BtbWNLTcrKvrKbzY2GA%40mail.gmail.com.
Michael Leone
Name your CDP/AIA something like pki.<domain>. If you name it pki.<host>.<domain> then you have to retain that host “forever”. (Yes, there are ways around this, but why complicate life?)
Dennis Pinckard
Am I Don in this scenario? :)
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/070edd7243ed497d9ffa7f57c169d34f%40smithcons.com.
Michael B. Smith
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/fc79832d-241d-e5db-c835-4ae4d62fc1c0%40doomsdaypig.com.
Dennis Pinckard
One of the main reasons is you don't want your certificates to leak information about your internal structure. "Ooh. His CA hostname must be 'cert002.domain', I'll attack that first!"
Don't tie the web site url to any specific machine. Otherwise,
that machine has to live for the lifespan of your certs. (Sure
you can rebuild with the same name, but why limit yourself at the
beginnning). Use a host header and it can be moved to any web
server. It can be scaled out to a farm of two or more webservers
for HA. (Take one down for maintenance and not impact users)
I like to keep my CDP/AIA named "pki.publicdomain.com". I don't HAVE to publish it to the internet, but with a split-dns I have that option. Say I want to implement Work Folders in windows and have it be available to my users. Only domain users would ever need or be allowed to access them and I need a trusted certificate on my web application proxy in the DMZ. Rather than spending money on a public cert, since all of my domain workstations already trust the internal PKI, I would publish my CDP/AIA to the Internet. Then when workstations are off the network, they can still validate my internally issued certificates.
Michael Leone
One of the main reasons is you don't want your certificates to leak information about your internal structure. "Ooh. His CA hostname must be 'cert002.domain', I'll attack that first!"
Don't tie the web site url to any specific machine. Otherwise, that machine has to live for the lifespan of your certs. (Sure you can rebuild with the same name, but why limit yourself at the beginnning). Use a host header and it can be moved to any web server. It can be scaled out to a farm of two or more webservers for HA. (Take one down for maintenance and not impact users)
I like to keep my CDP/AIA named "pki.publicdomain.com". I don't HAVE to publish it to the internet, but with a split-dns I have that option. Say I want to implement Work Folders in windows and have it be available to my users.
Only domain users would ever need or be allowed to access them and I need a trusted certificate on my web application proxy in the DMZ. Rather than spending money on a public cert, since all of my domain workstations already trust the internal PKI, I would publish my CDP/AIA to the Internet. Then when workstations are off the network, they can still validate my internally issued certificates.
Michael Leone
> Question: (you KNEW I would have one, right? :-))
>
> I am doing this (setting the crl location, etc) for my root CA in Linux. (I have not yet actually created the issuing CA in AD. I want to get the root completely correctly configured first)
Protocol (OCSP) should be included within the intermediary
certificate. This lets systems know where check and see if the
intermediary certificate was revoked by the root at any given time"
https://devcentral.f5.com/s/articles/building-and-openssl-certificate-authority-creating-your-intermediary-certificate-27888
So this info must be known to the root CA, so it gets included into
the intermediate cert when signed by the root.
(So this means that the root signs the intermediate CA cert using a
specific configuration set, which includes that crl and oscp/CDP/IAI
pointers)
> Do I need to do the same for the *issuing* CA (make a new CDP site)?
> Or does the issuing CA look to the same CDP site for the same crl file?
> If a cert is ever revoked (which is the purpose of the CDP), do I do the revocation on the issuing CA, or do I need to do that on the root CA?
> There only needs to be 1 CDP site, right? Not one each for the root and another for the issuing CA?
Dennis Pinckard
Sorry if this message gets duplicated. I sent it this morning, but it still hasn't appeared in my inbox.
Fortunately, in Windows, updating the CDP locations is easy to do, but only takes effect on certificates issued after that change. Since the CDP is embedded in the issued certificates, there's no way to update it within them after issuing other than re-issuing. I'm sure it would work the same on Linux.
I will again advise only including http CDP's in your issued certificates. In my Windows CA properties, on the "Extensions" tab, I will generally only have (NOTE: Windows will substitute the correct values for the <> variable placeholders. Don't fill them in yourself):
"C:\Windows\System32\CertSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl"
"file://c:\InetPub\PKIRoot\CDP\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl"
These entries will have "Publish CRLs to this location" and "Publish Delta CRLs to this location" checked. I will have a scheduled task to keep any other web servers in sync, if needed.
Additionally I will include:
"http://pki.domain.name/CDP/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl"
This entry will have only "Include in the CDP extension of issued certificates" checked.
Why do I only use HTTP? So non-domain and non-windows devices can access the CDP. So domain computers that are not on the network can access the CDP. Clients will start with the 1st CDP location and try to access it, if it times out, it will go to the next in the list. I prefer to just use http and ensure it is accessible internally and externally (when required). All clients should understand how to use http.
Notice above that the <CAName> is embedded in the filename of the CRL? This is a BIG reason to not use your hostname as the CA Name. Don't leak your internal names and make it easy for the bad actors.
Also, this means that one website can host all of your CDP's, AIA's, CPS's, etc. You CAN create a separate website for root and issuing, but that's just extra work, IMHO. You define the settings for each CA individually, but nothing says you can't set all of the published CDP's to the same web site. You will need to set up some method of getting the Root CA's CRL over to the PKI website every time your publish it. (Automation is your friend here!)
When you revoke a certificate, you are flagging that certificate in the database on the CA that issued it. Then that CA needs to republish the CRL to include that certificate. So you can ONLY revoke a certificate on the CA that issued it. A Root CA should only ever issue certificates for Issuing CA's and those are the only ones it knows about and the only ones it can revoke. Just remember if you revoke the cert for an issuing CA, then all of the certificates issued by that issuing CA just got invalidated. You broke the chain of trust.
Here's some of my CA links for additional reading in the spare time of a Network Admin:
https://social.technet.microsoft.com/wiki/contents/articles/10942.ad-cs-security-guidance.aspx
https://www.derekseaman.com/tag/certificate-authority
https://timothygruber.com/tag/pki/
https://blogs.technet.microsoft.com/xdot509/tag/operating-a-pki/
Michael Leone
<ntsys...@doomsdaypig.com> wrote:
>
> Sorry if this message gets duplicated. I sent it this morning, but it still hasn't appeared in my inbox.
So, here's what shows up in a test certificate I just issued.
CA$ sudo openssl x509 -noout -text -in certs/2019-06-24-test-1-cert.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = Pennsylvania, L = Philadelphia, O = PHA,
OU = ISM Dept, CN = <FQDN>, emailAddress = <emailo>
Validity
Not Before: Jun 24 13:44:02 2019 GMT
Not After : Jun 19 13:44:02 2039 GMT
Subject: C = US, ST = Pennsylvania, O = PHA, OU = ISM, CN =
fake-server.<domain>, emailAddress = <email>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<snipped>
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
PHA Internally generated Server Certificate
X509v3 Subject Key Identifier:
93:C1:18:BB:05:5E:23:53:2B:28:30:34:9A:71:51:97:4B:14:D9:C2
X509v3 Authority Key Identifier:
keyid:89:00:92:B7:98:A9:BD:08:49:3D:EE:B9:81:49:06:A7:6E:A9:8C:D8
DirName:/C=US/ST=Pennsylvania/L=Philadelphia/O=PHA/OU=ISM
Dept/CN=<FQDN>/emailAddress=<email>
serial:9F:F4:F2:FC:6D:C0:09:E4
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://pki.<domain>/pki_pha_crl.crl
Authority Information Access:
CA Issuers - URI:http://pki.<domain>/pki_pha_ocsp.crt
OCSP - URI:http://pki.<domain>
Signature Algorithm: sha256WithRSAEncryption
<snipped>
So I've got a 2048 bit key, with SHA256; a CRL listed, and no hostname
in the URI or the name of the CRL file.
As for the AIA and OCSP entries ... I pretty much made those up,
following the same URI scheme as the CRL. I'm still struggling to
understand those concepts; the CRL and it's uses and need, that I
understand. Eventually I will make a website with that URI, and put
the CRL file into it.
Problem is, when I import the CA cert into "Trusted Root" certs in
Windows, it shows as "Issued to" and the CA hostname, so I have
something wrong there. But it does show all the right purposes. I
don't have a tab called "Extensions" - just General,
Cross-Certificates, OCSP, and Extended Validation.
Worse, tho, I imported the signed client cert above, but I can't find
the silly thing. LOL. If I open an MMC for certificates, I don't find
that cert, even though it says it imported successfully ... Mind you,
that cert isn't from a web server, I just issued it from my root CA.
Still, it should appear somewhere ...
So while I'm making progress, I'm not there yet. I'll probably have to
re-issue that CA cert, so that when I import it, it doesn't have the
hostname in it. That shouldn't be too hard, I just need to make the CN
says something like "<company> offline root CA" or words to that
effect.
<SIGH>
Almost, almost. Once I can figure out the hostname, and figure out
where the cert went, I might be within sight of making the issuing CA
...
Michael B. Smith
The PSParentPath (in this case) tells you it is a machine certificate, located in the Personal (‘My’) store.
Thanks.
Regards,
Michael B.
-----Original Message-----
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com] On Behalf Of Michael Leone
Sent: Monday, June 24, 2019 10:27 AM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Re: More certificate confusion - issuing CA server config
On Fri, Jun 21, 2019 at 4:56 PM Dennis Pinckard
--
Michael J. 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>
Just backpacking through the Uncanny Valley ....
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To post to this group, send email to ntsys...@googlegroups.com.
Visit this group at https://groups.google.com/group/ntsysadmin.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BjjzFuVpdo1uv4OA49WQymdVNc%3D4CrVXk9ZU5z%2BPG7V%2BA%40mail.gmail.com.