Fixing the SSL Certificate with Project Honolulu

So if you haven’t heard of it yet Microsoft is doing some pretty cool stuff in terms of Local Server management in what they are calling Project Honolulu. The latest version, 1802, was released March 1, 2018, so it is as good a time as any to get off the ground with it if you haven’t yet. If you’ve worked with Server Manager in versions newer than Windows Server 2008 R2 then the web interface should be comfortable enough that you can feel your way around so this post won’t be yet another “cool look at Project Honolulu!” but rather it will help you with a hiccup in getting it up and running well.

I was frankly a bit amazed that this is evidently a web service from Microsoft not built upon IIS. As such your only GUI based opportunity to get the certificate right is during installation, and that is based on the thumbprint at that, so still not exactly user-friendly. In this post, I’m going to talk about how to find that thumbprint in a manner that copies well (as opposed to opening the certificate) and then replacing the certificate on an already up and running Honolulu installation. Giving props where they do this post was heavily inspired by How to Change the Thumbprint of a Certificate in Microsoft Project Honolulu by Charbel Nemnom.

Step 0: Obtain a certificate: A good place to start would be to obtain or import a certificate to the server where you’ve installed Project Honolulu. If you want to do a public one, fine, but more likely you’ll have a certificate authority available to you internally. I’m not going to walk you through this again, my friend Luca Dell’Oca has a good write up on it here. Just do steps 1-3.

Make note of the Application ID here, you’ll use it later

Step 1: Shut it down and gather info: Next we need to shut down the Honolulu service. As most of what we’ll be doing here today is going to be in Powershell let’s just do this by CLI as well.

Now let’s take a look at what’s currently in place. You can do this with the following command, the output should look like the figure to the right. The relevant info we want to take note of here is 1) The port that we’ve got Honolulu listening on and 2) The Application ID attached to the certificate. I’m just going to reuse the one there but as Charbel points out this is generic and you can just generate a new one to use by using a generator.

Pick a cert, not any cert

Finally, in our quest to gather info let’s find the thumbprint of our newly loaded certificate. You can do this by using the Get-ChildItem command like this

As you can see in the second screenshot that will give you a list of the certificates with thumbprints installed on your server. You’ll need the thumbprint of the certificate you imported earlier.

Step 2: Make it happen: Ok now that we’ve got all our information let’s get this thing swapped. All of this seems to need to be done from the legacy command prompt. First, we want to delete the certificate binding in place now and the ACL. For the example shown above where I’m using port 443 it would look like this:

Now we need to put it back into place and start things back up. Using the port number, certificate thumbprint, and appid from our example the command to re-add the SSL certificate would look like this. You, of course, would need to sub in your own information.  Next, we need to put the URL ACL back in place. Finally, we just need to start the service back up from PowerShell.

Conclusion

At this point, you should be getting a shiny green padlock when you go the site and no more nags about a bad certificate. I hope as this thing progresses out of Tech Preview and into production quality this component gets easier but at least there’s a way.

Support Adobe Digital ID Signing with Automated Microsoft CA User Certificate Generation

Just a quick how to, wanting to document a task I have recently had need of. This process has a perquisite of you having a Microsoft Certificate Authority already available in your environment.

  1. Start > Run >mmc
    1. Add Remove Snap-ins and choose the following
      – Certificate Authority (when prompted add the name of your CA)
      – Certificate Templates
      – Group Policy Management
  2. In Certificate Templatesright click on “User” and choose “Duplicate Template”
    1. Set compatibility settings as needed. If you have a 2008 R2 pure Active Directory environment make it match. In terms of Certificate Recipient make it match the oldest OS you have in use.
    2. Under General Change the Name to something meaningful as you’ll be referencing it later.
    3. Under the Security Tab set Domain Users to have both Enroll and Autoenroll permissions
  3. In Certificate Authorityright click on the “Certificate Templates”subfolder and choose New> “Certificate Template to Issue”
    1. Choose your newly created Certificate Template
  4. In Group Policy Management we are going to do a couple of things; setup your domain for certificate auto enrollmentand also define registry settings for Adobe Acrobat and Acrobat Reader.
    1. In any GPO that will hit the users you wish to have certificates (Default Domain Policy for example) choose to edit.
    2. Navigate to User Configuration> Windows Settings> Security Settings> Public Key Policies
    3. Double click on Certificate Services Client- Auto-Enrollment and set
      – Configuration Model: Enabled
      – Check Renew expired certificates…
      – Check Update certificates that use certificate templates
      – Hit OK
  5. Digital Signature Verification PreferencesBy default Adobe Acrobat and Reader only recognize certificates that are signed by the usual public authorities as trusted, so you have to tell it to look at what is available in the local Windows Certificate Store. In Adobe Acrobat or Acrobat Reader you can do this in Preferences, under Signatures>Verification and enable “Validating Signatures” under Windows Integration. This can be cumbersome across the enterprise but luckily this data is saved in a registry key, which means that through Group Policy Preferences we can manage this setting.  The fix below will work for all Acrobat or Acrobat Reader versions 7 or later
    1. Select the GPO of your choice to edit (again, I recommend the Default Domain Policy) and navigate to User Configuration> Preferences> Registry
    2. Right click in the window New> Registry Item
    3. You will need to create an entry with the following attributes:
      – Hive: HKEY_CURRENT_USER
      – Key Path: Software\Adobe\product\versionnumber\Security\cASPKI\cMSCAPI_DirectoryProvider
      * (Example for Acrobat Pro 11: Software\Adobe\Adobe Acrobat\11.0\Security\cASPKI\cMSCAPI_DirectoryProvider)
      – Value name: iMSStoreTrusted
      – Value type: REG_DWORD
      – Value data: 60 (hexidecimal)
      – Hit OK
    4. gp-prefRepeat steps B & C for each product/version combination you have in your environment. For example, in our environment we only have one version of Reader, but 3 different major versions of Acrobat Pro, so I needed 4 variants of this key to cover each of them.

And that’s it! It will probably take a little while for these policy changes to naturally propagate, but once it does so it works very slickly. Once done you and your users will be able to use their generated certificate as a Digital ID to sign any documents with a digital signature field in a fillable form. Do keep in mind that while this will work and absolutely can and should be trusted within your organization, if you or your users are in need of this type of service between organizations you will probably want to call the fine folks at Verisign or Thawte.

To for more information check out

Quick Config: Install ClamAV & configure a daily scan on CentOS 6

I’m pretty well versed in the ways of Anti-Virus in Windows but I’ve wanted to get an AV engine installed on my Linux boxes for a while now. In looking around I’ve found a tried and true option in ClamAV and after a few stops and starts was able to get something usable. I’d still like to figure out how to have it send me a report by e-mail if it finds something but that’s for another day; I don’t have enough Linux in my environment to necessitate me putting the time in for that.

So with that here’s how to quickly get started.

Step 0: If not already there, install the EPEL repository

Step 1: Install ClamAV

Step 2: Perform the 1st update of ClamAV definitions (this will happen daily by default afterwards)

Step 3: Enable and Start Services

Step 4: Configure Daily Cron Job

I chose to have it scan the whole system and only report infected files, you may want to do differently

Enter the following:

Note the -i option tells it to only return infected files, the -r tells it to recursively search. You may want to add the –remove option as well to remove files that are seen as infected.

Step 6: Make Cron Job Executable

You can then kick of a manual scan if you’d like using

That’s it! pretty simple and all of your output will be logged daily to the /var/log/clamav/daily_clamscan.log file for review.