You will see this error if you are migrating a Certificate Services Server from Server 2008, (NOT Server 2008 R2) to Windows Server 2016, (or newer).
Version of log file is not compatible with the Jet version 0xc8000202 (ESE: 514 Jet_errBadLogVersion)
You will also see the following events logged;
Event ID 17
Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Date: xx/xx/xxxx xx:xx:xx
Event ID: 17
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: 2019-CA.migrate.com
Description:
Active Directory Certificate Services did not start: Unable to initialize the database connection for MIGRATE-CA. Version of log file is not compatible with Jet version 0xc8000202 (ESE: -514 JET_errBadLogVersion).
OK, if you followed a good CA migration guide like mine here, then you already have a copy of the the Database, CA certs, Private keys, and Registry settings. So you are good, don’t panic.
This has happened because the source Jet Database that Certificate Services used on the old 2008 Server, (Note: not 2008 R2) is simply too old to be upgraded straight to the one on Server 2016 or newer.
You need to spin up a 2012 R2 server, migrate Certificate Services, onto that, then migrate to Server 2016 (or 2019) from there.
Related Articles, References, Credits, or External Links
I got an email about this last night, I rarely ever use the ASA as a Local CA, But that has now been completely depreciated, (post version 9.12(x)) The documentation tells us;
Local CA server is deprecated in 9.12(1), and will be removed in a later release—When ASA is configured as local CA server, it is enabled to issue digital certificates, publish Certificate Revocation Lists (CRLs), and securely revoke issued certificates. This feature has become obsolete and hence the crypto CA server command is deprecated.
OK, so if you want to ‘self sign’ certificates then you can use Microsoft Certificate Services.
Solution
Setting up Microsoft Certificate Services is a subject I’ve ‘done to death’ see the following article;
If you are retiring a CA Server, or there’s a problem with the server and you want to move Microsoft Certificate Services to another server, the procedure is pretty straight forward.
BE AWARE: We are moving the CA Server Name , NOT the Server Name (FQDN), the two things are NOT the same, (you might have called them the same thing!) But a Certificate Authority has a name of its own, and that’s what we are going to move.
So the new server doesn’t have to have the same name? No, it can do if you really want, but that’s an added layer of complication I can’t see the point of?
In the video below, I’m migrating from Server 2008 R2 to Server 2019, and I’m also moving CRLs and OSCP responders. In the screenshots below I’m moving from Server 2016 to Server 2016, but the process is pretty much identical all the way back to Server 2003.
Can I migrate from Server 2008 (NON R2) to 2016 (or newer): Yes, but not directly, you need to upgrade to Server 2012 R2 first. If you don’t, the database wont mount and you will get this error.
Solution
On the ‘Source‘ server, open the Certificate Services management console > Right click the CA NAME > All Tasks > Back up CA.
The backup wizard will open, Next > Tick BOTH options > Select a Backup Location > Next > Set a password (you will need this to set the new CA up!) > Next > Finish.
Now we need to take a backup of the Registry key that holds the information for this CA server. Run ‘regedit’ > Navigate to;
Export a copy of this key, (save it in the same folder that you backed up to earlier).
Now we need to uninstall CA Services from this server. Server Manager > Manage > Remove Roles and Services > Next.
REMOVE all the CA role services > Complete the Wizard, then launch the wizard again and select ‘Active Directory Certificate Services’ > At the pop-up select ‘Remove Features’ > Next.
Next > Next > Next > Close.
Setup Certificate Services on the Target/New Server
Server Manager > Add Roles and Features > Next.
Next > Select ‘Active Directory Certificate Services’ > Add Features > Next.
For now let’s just stick with the Certification Authority > Add the other role services later* > Next.
*Note: I’ve written about all these role services before, just use the search function, (above), if you are unsure what they all do.
Next > Close.
Warning > Configure Active Directory Certificate Services > Next.
Next > Enterprise CA (Unless it’s an offline non domain joined CA) > Root CA (unless it’s a subordinate CA!) > Next.
> Select ‘Use existing private key‘ > Select ‘Select a Certificate and use its associated private key‘ > Next > Import > Browse > In your backup folder locate the certificate (it will have a .p7b extension.) > Enter the password > OK > Select the Cert > Next.
Next > Next > Configure > Close.
Stop Certificate Services;
[box]net stop certsvc[/box]
If your new server has a different hostname/FQDN open the registry file you exported above with Notepad, locate and change the CAServerName entry to the name of the NEW server.
Right click the registry backup > Merge > Yes > OK.
Launch the Certificate Services management console > Right Click the CA NAME > All Tasks > Restore CA.
The restore wizard will start > Next > Browse to the folder with your backup in > Next > Enter the password you used (above) > Next > Finish.
You will be prompted to start the Certificate Services service > Yes.
What About Certificate Templates? Do I need to Move Them?
No! Certificate templates are actually stored in Active Directory, NOT in/on the actual Certificate Services server, (that’s why sometimes they take a while to appear after you create them!) You can see them here;
Related Articles, References, Credits, or External Links
I seem to get all the PKI/Certificate services problems! Yesterday I was trying to use the web enrolment portal on a certificate services server, and could not get in locally, (or remotely) via http, (or https) it simply showed me a 403.14 error.
HTTP Error 403.14 Forbidden
Solution
This was an odd one, in IIS Manager select the ‘Certsrv’ virtual directory > Advanced Options > And look at the ‘Path’.
Mine was missing the ‘en-us‘ folder from the end of the path!
Note: You will need to open an administrative command window, and then execute an iisreset command, before the change will take effect.
Related Articles, References, Credits, or External Links
In vSphere 5 and earlier versions this was not a ‘fun’ job at all, many times I sat down to do it, and lost the will to live. Now there’s a nice new tool built into vCenter that does ‘most’ of the hard work for you. Here I’m using the vCenter appliance but the tool is also available on the Windows version.
For my certificates I’m using Microsoft Certificate Services. I’m going to issue a ‘Subordinate CA’ certificate to my vCenter Appliance, then it can issue signed certificates to each of its services.
Solution
Make sure you have published a ‘Subordinate Certification Authority’ certificate template.
Connect the the vCenter appliance using SSH and enable ‘shell’
[box]
shell.set --enabled True
shell
[/box]
Create a directory to store our certificates and requests in, then launch the certification-manager tool.
The app will launch, and present you with a bunch of options.
Select option 2 > No we don’t want to use the configuration file > enter your logon information, (administrator@vsphere.local and password) > Enter all the items required for the certificate request.
Choose option 1 (Generate Certificate signing request) > Specify the folder you created above, (/root/SSLCerts) > Two files will be generated > Enter ‘2’ to exit.
The files;
vCenter 6.5
vmca_issued_key.key (the private key)
vmca_issued_csr.csr (the request)
vCenter 6.0.0
root_signing_cert.key (the private key)
root_signing_cert.csr (the request)
Now we need to get the CSR (signing request).
[box]
cat /root/SSLCerts/vmca_issued_csr.csr
OR
cat /root/SSLCerts/root_signing_cert.csr
[/box]
Copy the certificate PEM file.
Open the web enrolment portal of your certificate services server, (https://server.domain.com/certsrv) > Request a certificate > Advanced Certificate Request > Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file > Paste in the PEM text > Remember to use the Subordinate Certificate Authority template > Submit.
Base 64 Encoded > Download Certificate > Save it somewhere you can find it, and give it a sensible name!
Now download the Base 64 version of your CA certificate from the main page of your certificate services website, (press ‘back’ a few times).
Now back in your SSH session, change to your SSLCerts directory, and create an ’empty’ file to paste our certificate information into.
[box]
cd /root/SSLCerts/
touch vmca_signing_cert.cer
vi vmca_signing_cert.cer
[/box]
Open the certificate for the vCenter Appliance in a text editor, and PASTE INBELOW it, the text from the Root-CA certificate. Then copy ALL the text to the clipboard, and go back to the SSH session.
Paste the text you have coped into the open ‘vi editor’ page (Press I, then P) > Save and Exit (Press Esc > :wq {enter})
If you ‘ls’ (thats list short, or dir if you are a Windows type), you will see you now have a .CSR, a .KEY and a .CER file. (the names of which vary between version 6 and 6.5).
Version 6.5
Version 6.0
Launch the certificate-manager application again > Option 2 again > No (again) > Login (again) > ‘N’ > Option 2 (Import custom certificate(s)) > Give it the path to the certificate file > Then the path to the key file.
This is pretty much part two of the last article I wrote, so make sure you have the vCenter CA setup as a Sub CA of your Microsoft Certificate Services Deployment. See the following article;
Now we take the next step, and replace the certificates on the ESXi hosts.
Solution
Note: Joining the ESXi Hosts to the domain is not essential, it just makes things a little smoother. Ensure the host is set with the correct hostname and DNS settings.
Join the host to your domain.
vCenter 6.5
vCenter 6.0
Supply the domain name and suitable credentials.
Set the domain members to trust the vCenter CA Certificate. Back in part one we issued a SUB CA cert to the vCenter. Now I’m going to get a copy of this certificate, and get all my domain members to trust it, (and by definition all the certificates it issues). Browse to the vCenter https address > And open the certificate properties (click the padlock) > Certificate path > CA > View Certificate > Install Certificate.
Local machine.
I’m going to put it in Intermediate Certificate Authorities.
Then open an MMC console, and add in the certificate snap-in for Local Computer > Intermediate Certification Authorities > Certificates > Locate the ‘CA’ Certificate.
Export the certificate.
DER encoded is fine.
Save it on the root off the C: drive with a sensible name.
Open an administrative command window, and issue the following commands;
Now you will see the domain members start to get the CA certificate, (either in Intermediate or Root, depending on the command you issued above).
Meanwhile back in vCenter Web Client > Right click each host > Certificates > Refresh CA Certificates > Then Refresh Certificate.
WARNING: You may see the error below; if you do, it’s a bug don’t panic, there is a fix published on VMware Support. But if you wait 24 hours and attempt to renew the certificates it will work without an error.
A general system error occurred: Unable to get signed certificate for host: esx-host.your-domain.pri. Error: Start Time Error (70034).
You should see something like this;
If you browse to each ESXi host on https it should connect without errors or warnings.
Related Articles, References, Credits, or External Links
“I don’t know what it is about Certificates, I just don’t like them, I don’t understand them, and I don’t like working with them”
I hear this a lot, In fact I heard it this week, and as I’m usually the ‘go-to-guy’ for certificates and PKI, it winds me up! IT pros take the time to learn concepts like DNS, DHCP, Kerberos etc. But mention Certificate Services and heads disappear below monitors and silence decends.
OR WORSE: Someone adds the role, clicks Next > Next > Next > Job done! Lets have tea and medals!
So in typical PNL fashion lets simplify everything, get everyone on the same page. And most importantly, lay out how to do it so I don’t have to do it for you!
Solution
To design PKI well, you need to decide if you want a two or three tier PKI environment.
What can’t I just have one CA Server? (Hmm your the Next > Next > Next > Job Done Person Eh?) Well you can! But if that one server breaks, (or get compromised.) Then you are in trouble. Plan you deployment properly and save yourself a headache.
Two Tier Or Three Tier PKI? That’s your call, The main advantage of three tier PKI is, if one of your issuing servers, is compromised, you don’t need to bring the offline Root CA back online to re-issue its certificate. I have a client who have an issuing server in their DMZ so this was a good fit for them. For most domains Two Tier is the best option.
So I can only have one issuing Server? No, I just put one on the diagram for simplicity, you can have 1, or 100, or 1000, it’s up to you.
Do I need CRL (Certificate Revocation List) and/or OCSP (Online Certificate Status Protocol) On a Separate Server? Strictly speaking No, but it’s considered good practice, and if you need to advertise a CRL externally, it is more secure.
PKI Terminology Differences
You will notice I’ve mentioned a Root CA, an Intermediate CA, and an Issuing CA. This is to better explain the architecture and define a difference between an Intermediate CA, and an Issuing CA. Microsoft does not care,.Both of those servers are SubCA servers in Microsoft speak.
Deploying an Offline Root CA
Whichever architecture you choose this will be your fist step. The offline Root CA is a non domain joined machine, its sole job is to issue SubCA certificates to your intermediate CAs (three tier PKI), or issuing CAs (two tier PKI). When you have finished you power off the Offline Root CA and keep it off.
Note: In my example I want my Root CA Cert to last 20 years
Before You Install Anything: Create a CAPolicy.inf file you can edit it with notepad. You may want to change the validity period, you certainly will need to change the legal notice URL (more on this later) to your own domain FQDN (Note: If you need people outside your organisation, (either at a partner, or just someone the public internet) to see that, ensure that URL is addressable.
Save the CAPolicy.inf file to C:\Windows, Make sure it’s not called Capolicy.inf.txt, (or it wont work).
Launch Server Manager > Manage > Add Roles and Features.
Role Based > Next > Select the local server > Next > Select ‘Active Directory Certificate Services’ > Add Features > Next.
No other features are required > Next > Next > Certification Authority > Next.
Next > Next > Close.
Configure Active Directory Certificate Services.
Accept the default (local administrator) > Next > Certification Authority > Next.
Stanalone CA > Next > Root CA > Next.
Create a new private key > Next > Make sure the hash algorithm is SHA 256 (NOT SHA1) > Next.
Give the CA a sensible name > Next > Set the validity period (as mentioned above I’m going for 20 years) > Next.
All the default can now be accepted > Next > Next > Close.
Launch the Certification Authority Management console and make sure we have a green tick.
Now we need to ‘Stamp’ Certificates issued by this CA Server with some domain information, but we have no connection to the domain, so we need to do it manually. Open an administrative command window and execute the following commands;
Note: I want my SubCA certificate to be valid for 15 years, if you want longer/shorter then adjust the figures below
Now my Offline Root server is not connected to a network, (because that’s best practice,) and as it’s a virtual machine the only way to get files from it is to use a virtual floppy drive, Im going to copy both my Root CA Certificate and CRL file to my floppy drive.
Note: These command publish the CA Certificate, (and its CRL) into Active Directory. You can see where, if you open the path shown in the example in ADSIEdit.msc (CN=Public Key Services, CN=Services, CN=Configuration, DC={forest root domain})
When attempting to connect a host to a Certificate Enrolment Policy Server it worked but had the following complaint;
WARNING: The URI “https://{Host-Name}ADPolicyPRovice_CEP_{Method}/service.svc/CEP” was validated sucessfully but there was no friendly name returned by the remote machine.
Solution
On your certificate enrolment policy server, open the Internet Information Servers (IIS) Management console. Expand {Server-Name} > Sites > Default Web Site > ADPolicyProvider_CEP_Kerberos, (yours may not end with kerberos) > Application Settings.
Locate the Friendly Name section > Enter a descriptive name for your CEP portal > OK.
When attempting to connect a host to a Certificate Enrolment Policy Server I got this error;
The URI Entered above had ID : “{Random-GUID}”. This ID conflict with an existing ID
Solution
On your certificate enrolment policy server, open the Internet Information Servers (IIS) Management console. Expand {Server-Name} > Sites > Default Web Site > ADPolicyProvider_CEP_Kerberos, (yours may not end with kerberos) > Application Settings.
Open the ID field, and add a character to the end of it > OK.
I was configuring a ADCS (Active Directory Certificate Services) on a DC (Domain Controller) for a client today and wanted to setup web-enrolment. I gave the Certificate Service User permissions to the IIS_USRS Group and everything was going well. Then, this error popped up when assigning the service account in setup.
Solution
This can be easily fixed, just follow these instructions and then you will be cooking on gas! (Remember I am on a domain controller)
Go to Active Directory Users and Computers (dsa.msc) Locate the ‘Builtin’ container > then the Administrators group > and add your server account.
REALY: Yes, you need the right to ‘Log on Locally’, and remember this is a Domain Controller, try adding that right manually though GPO, its restricted.
So, when you try and authenticate for the Service Account in setup, it will come up with no errors
To prove that it’s not all smoke and mirrors, here is the user authenticated,
Related Articles, References, Credits, or External Links