Tech Stuff
Moving Certificate Services without disturbing the old CA
by Travis on Feb.17, 2023, under General, Tech Stuff
So, a buddy of mine is working on a project where he needs to move his CA. I tried looking for the article that outlined the process I followed, but alas, I was unsuccessful. What does that mean!? It means I’m writing an article. 🙂
So, scenario… you’re rocking an old CA that someone installed on your local DC. For whatever reason, you don’t like this and need to move. Easy! (sort of) There’s a lot of different moving parts here and there’s a lot of assumptions I’m going to skip past here as the meat of the issue looking to be resolved is really just shifting the services from one CA to another. In my own experience, I typically will deploy an offline root CA and an online subordinate CA and maybe (depending on the size of the environment) other servers to handle different roles such as NDES, SCEP, etc. or maybe you want to change your naming convention up a bit and do something like pki.domain.com in your environment. However, we’re not covering any of that today, just the migration of CA requests from one CA to another. If you REALLY want me to write a post on any of the above, send me a note. My email is very similar to my site with just adding an @ in place of a ‘.’ … just sayin. 😉
Assumptions:
- You’ve deployed a new CA or pair of CA’s into your environment.
- The old CA is running on an old DC or old Server you want to get rid of.
- You’re not doing anything crazy with your CA, just basic usage as I will not be covering identification of specific certificate template and version usage in this article.
USUAL DISCLAIMER: While these steps have worked for me, they may not work for you. I’m not responsible for you nuking your environment. 🙂Â
Steps to complete the move:
- Login to your old CA (as an Enterprise Administrator) and identify your AIA and CDP configuration. Just to make sure it doesn’t differ from standard.
- Open the Certification Authority Console
- Right Click the CA name and click ‘Properties’
- Click on the ‘Extensions’ Tab
- Document the distribution information for both your AIA and CDP portions. You can ignore the LDAP stuff, what you’re looking for looks similar to the following:
- CDP –
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
file://\\<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl - AIA –
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt
file://\\<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt
- CDP –
- Disable Delta CRL and Issue a long Revocation List (CRL)
- Open the Certificate Authority Console
- Right Click ‘Revoked Certificates’ and click ‘Properties’
- Uncheck ‘Publish Delta CRL’
- Change the value for “CRL Publication Interval” to 20+ years.
- Open a command line in admin mode and run ‘certutil -crl’ to issue the new list.
- Copy the old CA cert and CRL list files to your new server.
- Navigate to Windows\System32\CertSrv\CertEnroll on the original CA
- Copy the Root Certificate crt file and the certificate revocation list crl file to the new server in the same location.
(or whatever folder you chose to use for publishing your certificates via IIS on the new server) DO NOT RENAME THESE!
- Redirect the AIA and CRL distribution points of the old CA to the new CA.
You can accomplish this by doing a DNS name redirect (preferred) of the old CA to the new CA so that requests for http://oldserver.domain.com/CertEnroll/certificate.crt and certificate.crl are available. This is done so that the recorded CRL and AIA records in previously issued certificates are still valid so that when the CRL or validation is checked based on the certificate meta data, the url will still be available and valid. This is also why you DO NOT want to rename your old cert and crl from step 3. It *MUST* match entirely with the previously published information that you collected from step 1(4). - Document all used templates stored in AD and then remove them from the old CA to prevent any future publishing based on those templates.
ALL templates must be disabled/removed. Once completed, the old CA will no longer be able to issue new certificates.- Open an administrative command prompt on the old CA and execute ‘certutil -catemplates > c:\temp\catemplates.txt’ to get a full list of the templates.
- Launch the CA console on the old CA and navigate to ‘Certificate Templates’
- Make note of all leveraged certificate templates in this list.
- Highlight all of the templates in the list, right-click and select ‘delete’; this will not delete your templates from AD!
- There may be a case here where you’ve got some oddities. In most cases, all of your certs should be good, but in some cases you may wish to issue specific certificates that didn’t fall into the default category immediately from the new CA. Review the certificate templates used to issue active certificates by taking a look at ‘Issued Certificates’ section and look for anything that doesn’t match up to the default certificate templates. This is an older link, but the list should still be valid. Default Certificate Templates In most cases, I don’t think you need to do this but every now and then you’ve got some oddity out there that’s worth at least being aware of. Auto-Enrolled certificates do not apply here even if you did some custom stuff.
- Activate the leveraged CA Templates in the new CA.
- Login to the new CA and open the CA console as an Enterprise Administrator.
- Right-Click ‘Certificate Templates’, click ‘New’ then click ‘Certificate Template to Issue’
- Choose all the templates you documented in step 5(3) and click ‘OK’
- Disable/Remove the CA role from the old system. You can do this step immediately upon testing that the new CA is issuing certificates or you can wait a few days. Since you removed the templates from the old CA you will not be issuing new certificates, but sometimes I like to leave it up for a few days to reference anything that may come up should I have missed something. In regard to the old CA cert and crl files, I usually will take a look at the latest expiration date of issued certificates on the old CA prior to decommissioning and record/set a reminder of when that date comes and goes so that I can clean up the old CA and crl files from within the new CA at that time. No sense in letting it hang around if you’re not using it. 🙂
I hope this helps someone out there to not be too scared of moving some CA roles around. There’s a couple different ways you can do this, but I found that this method worked best for me when I wanted to preserve the old CA (albeit not issuing) for a little while to track down anything strange that may pop up.
Configure & Deploy DRBD on Ubuntu 20.04+
by Travis on Nov.21, 2021, under Tech Stuff
So, in an effort to try get some solid replication of my data to a secondary site, I tried a few options but ultimately decided to go with DRBD for simplicity. Below are the steps taken to get this up and running between two systems.
Information:
DRBD supports three distinct forms of replication.
A. Asynchronous replication. Most often used for ‘long distance’ replication. Keep in mind there is always the risk of *some* data loss for uncommitted writes in the event of a forced failover.
B. Memory synchronous replication. This is a semi-synchronous replication protocol. In the event of a forced fail-over no writes are lost, however, if there is a simultaneous failure on both nodes, destruction of the primary data store and the most recent writes completed may be lost.
C. Synchronous replication. Local writes on the primary node are not considered completed until the remote disk has confirmed. Loss of a single node will result in no data loss under any circumstance. Loss of both nodes and their storage simultaneously would result in data loss.
Assumptions:
- Server 1 will be called replica01 for its hostname
- Server 2 will be called replica02 for its hostname
- ip.ip.ip.ip is to be replaced with the IPs of your systems where necessary
- Unused mounted disk is /dev/sdc
- We’re using Protocol A for Asynchronous replication.
Preparation (actions done on both systems):
1. Create the file /etc/multipath/conf.d/drbd.conf and place the following in its contents:
blacklist {
devnode “^drbd[0-9]+”
}
2. Install drbd:
sudo apt-get install drbd-utils
sudo depmod -a
3. Modify the contents of your /etc/hosts file and add the following:
ip.ip.ip.ip replica01
ip.ip.ip.ip replica02
4. Create a new replica config in /etc/drbd.d called r0.res with the contents as outlined below. Important things to note here is that the disk device that is specified is the disk outlined in assumptions. Also make sure to change your shared-secret.
resource r0 {
protocol A;
startup {
wfc-timeout 15;
degr-wfc-timeout 60;
}
net {
cram-hmac-alg sha1;
shared-secret “secret”;
}
device /dev/drbd0;
disk /dev/sdc;
meta-disk internal;
on replica01 {
address ip.ip.ip.ip:7788;
}
on replica02 {
address ip.ip.ip.ip:7788;
}
}
5. Initialize the meta data storage.
sudo drbdadm create-md r0
sudo service drbd start
6. On the primary host ONLY.
sudo drbdadm — –overwrite-data-of-peer primary all
sudo mkfs.ext3 /dev/drbd0
sudo mkdir /drbd-vol
sudo mount /dev/drbd0 /drbd-vol
Testing:
To verify the system is working as expected. we’re going to run a test.
1. Let’s create a file on our new volume and fill it with some kind of data. Feel free to copy other things there if you’d like too. Just nothing too large right now.
ls -lahR /etc >> /drbd-vol/output.txt
2. First, we’ll unmount from the primary node (replica01) and demote it to secondary.
sudo umount /drbd-vol
sudo drbdadm secondary r0
3. Now, we’ll promote the secondary node (replica02) to primary and mount the volume there.
sudo drbdadm primary r0
sudo mount /dev/drbd0 /drbd-vol
4. Confirm your previously created file(s) are there and that the contents are present. You should see the output.txt file and any other contents you copied.
ls /drbd-vol/
cat /drbd-vol/output.txt
5. Reverse the previous process from replica02 back to replica01 to restore the original configuration.
Other Info
You can take a look at the status of replication at any point by running the following command:
watch -n1 cat /proc/drbd
The second line of the output (sample below) has the following counters and informational data.
version: 8.4.11 (api:1/proto:86-101)
srcversion: FC3433D849E3B88C1E7B55C
0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate A r—–
ns:224 nr:18515180 dw:155350536 dr:2801 al:12 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
Meaning of each field:
- ns (network send) Total data sent to peer (KB)
- nr (network receive)Â Total data received by peer (KB)
- dw (disk write)Â Data written to the local disk (KB)
- dr (disk read)Â Data read from the local disk (KB)
- al (activity log) Number of updates to the activity log of the meta data.
- bm (bit map)Â Number of updates to the bitmap of the meta data.
- lo (local count)Â Number of open requests by local subsystem issued by DRBD.
- pe (pending)Â Number of requests sent to the primary peer that have not yet been answered.
- ua (unacknowledged)Â Number of requests received by the peer that have not yet been answered.
- ap (application pending) Number of block IO requests sent to DRBD, but not yet answered by DRBD.
- ep (epochs) Number of epoch objects which is usually 1. can increase under IO load when using either the barrier or the none write ordering method.
- wo (write order) Current write ordering method: b(barrier), f(flush), d(drain) or n(none).
- oos (out of sync)Â Amount of storage currently out of sync (KB)
Searching Certificates with certutil.exe
by Travis on Apr.08, 2021, under Tech Stuff
Dropping this one here for future reference…
I had a coworker ping me this morning asking to find a certificate using certutil.exe and the Issued Common Name. It took me longer than I’d prefer to remember how to do that so I’m posting it here for use later. 😀
certutil -view -restrict ‘CommonName=
You know, because this one WILL come back at me in short order. lol
Import DNS Files to Azure DNS
by Travis on Jul.23, 2020, under Tech Stuff
Because I literally forgot how to do this and had to look it up and don’t want to suffer through a long MSFT document again in the future….
Super short version FTW:
- Setup a new DNS zone in Azure. This is pretty easy, but in case you need it: https://docs.microsoft.com/en-us/azure/dns/dns-getstarted-portal
- Gather your dns file…
- Windows – C:\Windows\System32\dns
- Bind – Wherever you specified to drop those things for named to pick up (usually somewhere in /etc/namedb/ or /usr/local/etc/namedb/)
- Mod the file and pull out the NS records. Import doesn’t seem to like these despite what the doc’s say. 🙂
- Start Azure CLI (Cloudshell/Bash). If you don’t know how to use this, check this link: https://docs.microsoft.com/en-us/azure/cloud-shell/overview
- Upload your .dns file using the CloudShell console. I suggest you move the file into a working directory if you’d like to store it for later.
- Execute Order 66… err… this command:
- az network dns zone import -g domain-services -n domain.net -f domain.net.dns
- Profit
You should see a message along the lines of ‘== 41/41 RECORDS IMPORTED SUCCESSFULLY: ‘domain.net’ ==’ when completed, however you may want to go in and recheck the import and maybe make a few mods to any records you want to modify TTLs on, etc. Any TTLs not explicitly defined will set to 3600 so make sure to cleanup what you need, where you need.