Migrating an old non-MS Cert Authority to a new CA in AD
Michael Leone
PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>
Michael B. Smith
You can completely control the Windows CA from the command line if you want. J
Certutil.exe and certreq.exe.
Some things are MUCH easier to do in the GUI though.
You can import a private key from another Windows CA (as part of the migration process). And as long as it has the proper EKU, I guess it could be from a Linux CA, but you wouldn’t have all the necessary registry settings to actually make it a “clone” or “migration” of the Linux CA.
I wouldn’t recommend it without testing it extensively in a lab. I doubt what you seem to want to do (migrate from a Linux CA to a Windows CA) is supported. In fact, as I go through the various steps in my head, I’m certain it isn’t supported. Absent anything else, there would be no way for the Windows CA to attest to a CRL or to attest to the validity of a specific cert from the old CA.
What kind of certs are generated by a Windows CA is configuration dependent. It can generate shiny new certs or old polished certs and anything in-between.
I strongly recommend you put the CA on a standalone server.
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%2BiMaU_YMNrTbT7qntB8DQFAMvU-642quEYQqcGUQoUXyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Michael Leone
You can completely control the Windows CA from the command line if you want. J
Certutil.exe and certreq.exe.
Some things are MUCH easier to do in the GUI though.
I wouldn’t recommend it without testing it extensively in a lab. I doubt what you seem to want to do (migrate from a Linux CA to a Windows CA) is supported. In fact, as I go through the various steps in my head, I’m certain it isn’t supported. Absent anything else, there would be no way for the Windows CA to attest to a CRL or to attest to the validity of a specific cert from the old CA.
I strongly recommend you put the CA on a standalone server.
Michael Leone
I strongly recommend you put the CA on a standalone server.
Michael B. Smith
Sorry. Domain member is fine. In fact, I recommend that, for the AD integration.
I meant don’t put it on a DC, or a SQL server, or an Exchange server, or a Remote Desktop Session Host, etc.
You need the old CA around as long as any certs it generated are still in use.
A CA has several names. There is the name of the computer on which it is hosted (attribute ‘name’), there is the dnsName of the computer on which it is hosted (attribute ‘dnsName’), and there is the name of the CA itself (attribute ‘cAName’).
The middle one has to be unique in DNS. The other two don’t matter so much. The uniqueness you are likely referring to is held (by AD) as cACertHash – the hash of the CA certificate. And if you were hosting multiple CAs within a single AD forest (which is perfectly legal), each CA would require a unique cAName.
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com] On Behalf Of Michael Leone
Sent: Tuesday, June 11, 2019 2:15 PM
To: NTSysAdmin
--
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%2Bj0tf5QufbUZ%3Dzm-0BF%2BFeh8aK_ve%2B0JW_4JBpJPu66sw%40mail.gmail.com.
Michael B. Smith
Nah, create an enterprise CA. Again, for the AD integration.
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com] On Behalf Of Michael Leone
Sent: Tuesday, June 11, 2019 2:25 PM
To: NTSysAdmin
--
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%2Bhh3OLrVvzyhe2BBxRJkvmRro0njxoH-1GSR3Y9rspZEw%40mail.gmail.com.
Michael B. Smith
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/23334d5eafb0463482bcc9b59883f3d3%40smithcons.com.
Michael Leone
I meant don’t put it on a DC, or a SQL server, or an Exchange server, or a Remote Desktop Session Host, etc.
Ah, OK. No, I'd roll out a new Win 2016 VM dedicated solely to this task.
You need the old CA around as long as any certs it generated are still in use.
A CA has several names. There is the name of the computer on which it is hosted (attribute ‘name’), there is the dnsName of the computer on which it is hosted (attribute ‘dnsName’), and there is the name of the CA itself (attribute ‘cAName’).
Michael B. Smith
Those damn things (CAs) either last less than 6 months or they last forever. I’ve got CAs at some clients that have been around for 20 years and are on their 4th or 5th hardware iteration… Most of them are still named after the first server they were installed on.
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Michael Leone
Sent: Tuesday, June 11, 2019 2:36 PM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
On Tue, Jun 11, 2019 at 2:26 PM Michael B. Smith <mic...@smithcons.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%2BgqkWUz3Z2jJ8hCs8vft5mMAsPJ3oBxqNxhZiu%3DNG-Tug%40mail.gmail.com.
Kurt Buff - GSEC, GCIH
https://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx
https://blogs.technet.microsoft.com/askds/2010/08/23/moving-your-organization-from-a-single-microsoft-ca-to-a-microsoft-recommended-pki/
https://blogs.technet.microsoft.com/pki/2012/01/27/decommissioning-an-old-certification-authority-without-affecting-previously-issued-certificates-and-then-switching-operations-to-a-new-one/
Kurt
Michael B. Smith
Thanks.
Regards,
Michael B.
Michael Leone
Michael Leone
CR Hiestand
--
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%2BgqkWUz3Z2jJ8hCs8vft5mMAsPJ3oBxqNxhZiu%3DNG-Tug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Michael Leone
Use Server 2019 if possible.
Kurt Buff - GSEC, GCIH
The root CA should be kept powered off, unless and until you need to
renew the cert for the issuing CA. This is basic security 101.
Seriously - keep your root CA out of the domain, and powered off.
https://en.wikipedia.org/wiki/Offline_root_certificate_authority
Kurt
> 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 B. Smith
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Michael Leone
Sent: Tuesday, June 11, 2019 3:41 PM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
On Tue, Jun 11, 2019 at 3:39 PM CR Hiestand <cr.hi...@gmail.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%2Bj5AhJ5j5gn_%3DbwrOZj36k8CC%2Bs0GXps8nf%2Bhy9nrJe8Q%40mail.gmail.com.
Michael B. Smith
Best practice is an offline root.
There is no question it adds a significant additional layer of complexity and that many people aren’t willing to do spend that effort.
You aren’t paying me for my opinion so I won’t give you one. J
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Michael Leone
Sent: Tuesday, June 11, 2019 3:33 PM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
On Tue, Jun 11, 2019 at 2:28 PM Michael B. Smith <mic...@smithcons.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%2BheLnHzqoroa_FMTfPzR6o36AoXHndvtCW7T0036jiMeQ%40mail.gmail.com.
Michael Leone
Best practice is an offline root.
There is no question it adds a significant additional layer of complexity and that many people aren’t willing to do spend that effort.
You aren’t paying me for my opinion so I won’t give you one. J
Dennis Pinckard
In my opinion, this is one of those areas that, as an enterprise, you want to build it like an enterprise. At least a two-tier CA.
Kurt's links are great resources and building the CA's aren't
hard, they are just easy to screw up the first dozen times! Be
wary of most web based walkthroughs. They are almost all "not for
production" posts that just accept the defaults. Don't do that. A
lot of the settings with your CA's you only get once chance. Mess
it up and you rebuild it all from scratch.
Use Server 2019 and get the additional years of support. A CA should last you 10 years at least, make sure it's supported for most of its lifespan.
Build in a lab first, then tear it down and do it again. Repeat
until you understand all of the settings you need to configure.
Build a non-domain joined Root CA. It's a best practice for a reason.
Build your issuing CA(s). Depending on the size of your org, it may be worth it to build one for servers, one for workstations, one for users, one for non-windows gear, or a combination of any of these.
I'll add a link to Kurt's list:
https://777notes.wordpress.com/2016/07/11/certificates-the-dos-and-donts-of-pki/
It's a copy of the original author's post, which is no longer
available. Just keep in mind it is from 2012.
There's no need to migrate your old CA keys/name/etc to the new one. You can have multiple CA's in your environment, you just need to trust them. I would remove the templates from the old CA (Google how to prevent your CA from publishing new certs). Review the issued certs and re-issue them from the new CA. Once all of your certs have been re-issued and REVOKED on the old CA, you can turn it off and remove any root certs from your cert stores.
--
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%2BheLnHzqoroa_FMTfPzR6o36AoXHndvtCW7T0036jiMeQ%40mail.gmail.com.
CR Hiestand
--
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%2Bj5AhJ5j5gn_%3DbwrOZj36k8CC%2Bs0GXps8nf%2Bhy9nrJe8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Heaton, Joseph@Wildlife
Plus the STIG for 2019 just came out, so you can tighten it down.
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of CR Hiestand
Sent: Tuesday, June 11, 2019 3:19 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
Fixed patching alone should make 2019’s case for itself.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BDi7Ptsje5Ogfdvm0ae_F4d_5P5_qn793dCYEb7MqJPHt8zuQ%40mail.gmail.com.
Michael B. Smith
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Dennis Pinckard
Sent: Tuesday, June 11, 2019 5:48 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
In my opinion, this is one of those areas that, as an enterprise, you want to build it like an enterprise. At least a two-tier CA.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2ef83181-5165-e75c-95b8-3d48b66f610a%40doomsdaypig.com.
Michael Leone
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2ef83181-5165-e75c-95b8-3d48b66f610a%40doomsdaypig.com.
For more options, visit https://groups.google.com/d/optout.
Michael B. Smith
Thanks.
Regards,
Michael B.
From: ntsys...@googlegroups.com [mailto:ntsys...@googlegroups.com]
On Behalf Of Michael Leone
Sent: Wednesday, June 12, 2019 11:14 AM
To: NTSysAdmin
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
Quite honestly, from looking at everything that needs to be done, I'm almost tempted to just create a new CA on a new Linux VM; That's what I have now, and have used, for the last 9 years.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BjY39hqsZns6R4NoJM%3D6mN6zVAQiX9g5Vgejnvy%2ByVxUw%40mail.gmail.com.
Robert ECEO Townley
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BjY39hqsZns6R4NoJM%3D6mN6zVAQiX9g5Vgejnvy%2ByVxUw%40mail.gmail.com.
Robert ECEO Townley
Dennis Pinckard
As a former RHCE and Linux user for 25-ish years, I'm all for using Linux. BUT, I would ask that you look where are you going to use your certificates. If it is primarily on Windows machines, I think making your issuing CA a Windows CA is the better move. Make your root CA a linux box with a 4096-bit, SHA256 cert. Have it generate a cert for your domain-joined Windows Issuing CA and move forward.
Honestly, standing up a two-tier Windows CA is a few hours worth of work. (It's just a lifetime of research and prep!)
Keep an eye on what you MIGHT use the CA for as well. There's a lot of Microsoft features and services that use certs and auto-enrollment is definitely the way to go. I've never set up a Linux CA to serve Windows users and desktops, so I'd be curious how it would operate and be managed in that scenario.
Some final words of advice:
If you want to do it "by the book", get your own OID and use that
on your root CA. Even if you don't think you need this level of
attention to detail, it's a simple, free exercise and you are set
for the future.
Don't publish your CRL to AD/LDAP. Just use HTTP. Say you issue a cert to a Cisco switch. Can that switch access AD/LDAP to look it up? Probably not. At best it will timeout and delay looking up via HTTP.
Don't forget about CA server maintenance. We have an old CA that
has a HUGE database. So huge the MMC console won't open. No one
seems to talk about the routine maintenance that a CA server
requires. I've recently built a Powershell script that is
scheduled on the new CA to keep it lean.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BjY39hqsZns6R4NoJM%3D6mN6zVAQiX9g5Vgejnvy%2ByVxUw%40mail.gmail.com.
Melvin Backus
Can you enlighten us on the maintenance aspect? Perhaps a link to “The Care and Feeding of Windows CAs” so to speak?
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
¯\_(ツ)_/¯
From:
ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Dennis Pinckard
Sent: Wednesday, June 12, 2019 3:08 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
As a former RHCE and Linux user for 25-ish years, I'm all for using Linux. BUT, I would ask that you look where are you going to use your certificates. If it is primarily on Windows machines, I think making your issuing CA a Windows CA is the better move. Make your root CA a linux box with a 4096-bit, SHA256 cert. Have it generate a cert for your domain-joined Windows Issuing CA and move forward.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/5454bb75-66be-f3ae-1a16-4303873cc2cf%40doomsdaypig.com.
Michael Leone
As a former RHCE and Linux user for 25-ish years, I'm all for using Linux. BUT, I would ask that you look where are you going to use your certificates. If it is primarily on Windows machines, I think making your issuing CA a Windows CA is the better move. Make your root CA a linux box with a 4096-bit, SHA256 cert. Have it generate a cert for your domain-joined Windows Issuing CA and move forward.
Honestly, standing up a two-tier Windows CA is a few hours worth of work. (It's just a lifetime of research and prep!)
Don't publish your CRL to AD/LDAP. Just use HTTP. Say you issue a cert to a Cisco switch. Can that switch access AD/LDAP to look it up? Probably not. At best it will timeout and delay looking up via HTTP.
Don't forget about CA server maintenance. We have an old CA that has a HUGE database. So huge the MMC console won't open. No one seems to talk about the routine maintenance that a CA server requires. I've recently built a Powershell script that is scheduled on the new CA to keep it lean.
Philip Elder
I’m late to the party and TL;DR due to being busy with fires … however, has this one been passed along?
It’s a bit dated but would be one option to keep things buttoned up nice and tight.
Philip Elder MCTS
Microsoft High Availability MVP
E-mail: Phili...@mpecsinc.ca
Phone: (780) 458-2028
Skype: MPECS Inc.
Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of Michael Leone
Sent: Wednesday, June 12, 2019 13:20
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
On Wed, Jun 12, 2019 at 3:08 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%2BgBo4B-__%3Dfk4GhAOBepXC%2BAsjmKUbT7EL4-8uDyJhseA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Robert ECEO Townley
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/815653ed171d46c88654e5b5384f7bb2%40MPECSInc.Ca.
Dennis Pinckard
I've attached a "scrubbed" version of my maintenance script.
Usual warnings apply.
The actions of the script include:
* Full Backup the CA Database to D:\Backup\<date>
* Password protected backup of CA private key to
D:\Backup\<date>
* Export of CA registry keys to D:\Backup\<date>
* Compress and Archive backup directory
* Delete backup archives older than 90 days
* Deletion of failed certificate request records older than 14
days
* Deletion of expired certificate records (that do not require
key archival) older than 90 days
* Compress IIS logs older than 14 days
* Delete IIS logs older than 90 days
* Email report detailing above actions
* Email report summarizing CA activity for previous week (Not yet
implemented)
Places to edit include:
Line 82: [String[]]$EmailRecipient = ("us...@example.com") # default to account running the script.
Line 257: $MailSMTPServer = "smtpserver.example.com"
Line 258: $EmailSender = (get-content env:computername) + "@example.com"
Line 292: $backupBaseDir = "D:\Backups\"
The script has two main dependencies: 7-Zip and the Powershell Credential Manager module (https://www.powershellgallery.com/packages/CredentialManager/2.0)
I wanted to keep the password used for backing up the CA out of plain text, so I use a dedicated service account on the CA server and store the password in Windows Credential Manager as "CAPassword". That information is encrypted against that user account. The module allows the script, running under the same service account to access that password. Alternatively, a password can be provided as a parameter.
It is not as fully commented as I would like, but I think it's adequate to describe what's happening.
To create the script, I used information from these and other sites:
https://blogs.technet.microsoft.com/askds/2010/08/31/the-case-of-the-enormous-ca-database/
https://blog.ahasayen.com/microsoft-ca-database-cleanup/
Melvin Backus
T H A N K Y O U !!
Way more than I was anticipating. This group never fails to amaze me.
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
¯\_(ツ)_/¯
From:
ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Dennis Pinckard
Sent: Wednesday, June 12, 2019 4:07 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Migrating an old non-MS Cert Authority to a new CA in AD
I've attached a "scrubbed" version of my maintenance script. Usual warnings apply.
--
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/90de1821-1cec-482d-59cc-dbaeb0a76ffa%40doomsdaypig.com.