SSL Certificates and SAN – What domain names are valid?

An SSL certificate has a field called Subject. The Subject field contains the domain name that the certificate is valid for. Subject can only contain one domain name:

image

image3

The field Subject can have more information, like the screenshot below, but still only one domain name:

image

An SSL certificate can also contain an optional field called Subject Alternative Names, or – as it is more often called – a SAN field. The SAN field contains one or multiple domain names that the certificate is valid for.

image6

Note that in this example I only have one single SAN name. You can have many domain names in the SAN field of a certificate.

A common misconception around this is that a certificate with both Subject and SAN is valid for all domain names that are present in both of these fields. But if an SSL certificate has a SAN field, then SSL clients are in fact supposed to ignore the Subject field and look only in the SAN field for a domain name match.

This behavior is clearly specified in the RFC for HTTP Over TLS:
http://www.ietf.org/rfc/rfc2818.txt

“If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used.”

In other words: If SAN exists, use only that. If no SAN exists, use Subject.

To see this behavior in action, see my short video below [52 sec], in which I use the certificate from the screenshots above on two different websites: san.tomdemo.se and subject.tomdemo.se. Can you predict what will happen?
[the video has no audio]

Since the Subject field is not used when using SAN, it can be set to anything, it could in fact be empty.

Perhaps a new best practice would be to set the Subject to something that would avoid the risk of this confusion whenever a SAN is used, like this certificate:

image

Posted in Certificates, PKI, SAN, SSL | Tagged , , , | Leave a comment

Get a free publicly trusted SSL-certificate

temp2

This blog post will guide you through the steps of obtaining a publicly trusted SSL certificate with up to 5 domain names, at no cost. There are no hidden costs, ads or referrals involved.

You do need to be able to verify that you own the domain name that the certificate will be issued for. You can do this by either receiving a verification code via email (sent to specific administrative email addresses of the domain) or the ability to publish a text file with a verification code on a webserver running on that domain.

I am using the Chinese certificate provider WoSign. Before you stop reading just because of this, consider that their ONLY involvement in this is procedure to sign your public key. They never see your sensitive private key, which is created on your computer and never leaves your control at any time.

Didn’t you know that your Windows computer most likely already trusts WoSign Root CA? Read my short blogpost Which Root CAs do you really trust?

If you want to verify that your client really trusts certificates obtained using this guide, please visit this link: https://test.tomdemo.se  You should not receive any certificate warnings. If you do, please let me know what browser/device you are using via the comment section below.

There are other ways to obtain free SSL certificates, such as Let’s Encrypt and StartSSL, but at the moment I prefer WoSign, since they allow you to add 5 SAN attributes for free.

Ok, lets go.

Create the key pair

The best option, to reduce the number of steps and also the risk of exposing the private key of the certificate, is to create the key pair directly on the computer that will actually use the certificate. But you can export the certificate and private key when you are done, so you can use any trusted Windows computer for the enrollment process. If you plan to use multiple SAN names, it’s likely that you must export the certificate to other computers anyway.

Normally you specify attributes when creating the key pair and the corresponding CSR (certificate signing request), such as Subject, Validity Time, SAN, Key Usage and so on, but WoSign will ignore all attributes in the CSR, and only use the public key. You specify the attributes in the enrollment flow at WoSign instead.

Certificate requests can be created in many ways, in this guide I am using the MMC snap-in.

Run certlm.msc to open the local certificate store for the computer.

Right-click Personal / Certificates, expand to All Tasks / Advanced Operations and click Create Custom Request:

image

On the Before You Begin page, click Next:

image

On the Select Certificate Enrollment Policy page, click Next:

image

On the Custom Request page, select (No template) Legacy key, make sure that the Request format is PKCS #10, and then click Next:
Note: I choose Legacy key for compatibility reasons, you might want to choose CNG key if you are sure that your services are compatible with this.

image

On the Certificate Information page, click on the down-arrow next to Details and then click Properties:

image

Click the Private Key tab. Click the down-arrow next to Key options and change the key size to 2048. Optionally select Make private key exportable (which I recommend, see the update at the bottom of this post why), then click OK:
Note: No other certificate information needs to be entered at this point.

image

Back at the Certificate Information page, click Next

On the Where do you want to save the offline request? page, enter a path and filename for your certificate signing request, make sure the File format is Base 64, then click Finish:

image

Now we have created a key pair and a Certificate Signing Request.

 

Create the certificate at WoSign

Direct your browser to the following URL:
https://buy.wosign.com/free/

Add the domain names you want to have a publicly trusted SSL certificate for. Make sure that the cost remains zero (US$0):

image

You may add additional domain names and also extend the certificate validity to 3 years, but that means that the certificate will no longer be free, and that is not the topic for this blogpost. Note that the cost is not updated until you click outside of the Domain name textbox.

Notice that I added domain names from two different domains, tomdemo.se and mssec.se, just to show how domain verification looks in this scenario.

Now you have to either create an account or login with an existing one. WoSign helps you determine if you created an account with them when you fill in your email address. I use a dedicated email address for this, but I have never received any email from them after enrolling the certificate.

If you have an account, it will look like this (you need to click outside of the Email textbox to trigger the check):

image

Click on the link forget password? to reset your password (it should be forgot, I know).

It you have not registered an account with the email you provide, you will instead be given the option to Send Verification Email:

image

Click the Send Verification Email button:
Note: This will start a 30 second countdown, but don’t panic, the only thing that will happen when the countdown reaches zero is that you will have the option to resent the verification code.

image

The verification email might take a 5-10 minutes to show up in your Inbox, do not request a new verification to fast.

Copy the verification code from the mail that you eventually receive:

image

Paste the Verification code in the field Verification code.

Enter an Account password for your WoSign account.

Enter the captcha. If it is hard to make out the characters you may click change it to get a new one (it will not reload the page or remove the other info you have entered).

Check the I have read and agree checkbox (you read the agreement, right?  Smile)

image

Click the Submit request button.

You are now taken to a page that looks like this:’’

image

If you see Chinese characters, click on the link called ENGLISH at the top of the webpage.

At this point we have created an “order” for a free certificate and supplied the names we want in the certificate, but we have yet to verify that we own the domains and to supply the public key we created earlier.

Click on the link Domain Control Verification.

We can now prove that we own the domain by either using special email accounts (that hopefully are reserved to admins of the domain):

image

or by placing a special file on the webserver:

image

I will continue with email verification in this guide.

Select the email address you have access to and click the Click to send verification Email button. A countdown similar to the one when we created the WoSign account appears. Wait until you receive the verification email, that will look like this:

image

The sender is autovalidation@wosign.com, remember to also check your spam mailbox.

Enter the verification code in the Verification Code field. Also complete the captcha and then click Verify Now:

image

If the verification succeeds, you will be prompted to verify the next domain (assuming that you entered different domains when requesting the certificate):

image

The verification of the next domain looks identical, so I do not show those steps here.

Note that once you verified your domain you can later request new certificates (within the same domain) without the verification step, which makes it much easier.

When all domains are verified you are taken to the Generate the Certificate Signing Request(CSR) page. This is a bit misleading, since we do not want the generate the CSR at this point, we want to submit the CSR we have already created.

Open the previously created CSR-file in notepad and copy all of the text:

image

Make sure that Option 2:Submit the CSR is selected. If you choose Option 1, WoSign will create the public and private key for you, and we do not want this.

Paste the text content of the csr-file in the textbox that says Please paste Certificate Signing Request.

Click Check CSR and make sure the text box on the right says

Encryption algorithm:RSA
Key length:2048bite     (yeah, should be “byte”)

image

Remember that the file only contains the public key, the sensitive private key is still safely stored on your computer that created the request.

Click the Submit button.

Now your certificate should be issued. Click on the link in the blue box to download a zip file containing your signed certificate:
Note: You will also get an email saying that the certificate is ready for collection. You can ignore this mail.

image

You will get this message:

image

This warning is only relevant if WoSign generated the private key and the CSR, the public part of the certificate will be available for download when you login with your WoSign account:

image

The downloaded zip file contains 4 other zip files, with the certificate and it’s issuers certificates in formats optimized for 3 different webservers:

for Apache
1_root_bundle.crt
2_adfs.tomdemo.se.crt

for IIS
1_cross_Intermediate.crt
2_issuer_Intermediate.crt
3_user_adfs.tomdemo.se.crt

for Nginx
1_adfs.tomdemo.se_bundle.crt

for Other Server
1_cross_Intermediate.crt
2_issuer_Intermediate.crt
3_user_adfs.tomdemo.se.crt
root.crt

 

Import the certificate

The last step is to import the signed certificate to the server that created the CSR.

Extract the file 3_user_adfs.tomdemo.se.crt.

On the server that created the CSR, run certlm.msc to open the local certificate store for the computer.

Right-click Certificate Enrollment Requests / Certificates and click All Tasks / Import:

temp

Note: There are other ways to import a certificate, but this way makes sure that the waiting private key and the imported certificate are correctly associated.

On the Welcome to the Certificate Import Wizard page, click Next:

image

Browse and select to the file 3_user_adfs.tomdemo.se.crt:

image

Change to Automatically select the certificate store based on the type of certificate and click Next:

image

On the Completing the Certificate Import Wizard page, click Finish:

image

You should see the message The import was successful:

image

You now finally have a publicly trusted SSL-certificate (with up to 5 domain names), all without paying a single penny:

image

If you export the certificate you will have the option to include the private key (if you selected this option earlier):

image

Here are some screenshots of the certificate:

image

image

image

 

Known issue with IIS

If the certificate is flagged as untrusted by clients when using the certificate in IIS, try importing the following certificates – that are included in the zip file – into the Intermediate Certification Authorities / Certificate (only on the IIS server itself!):

  • 1_cross_Intermediate.crt
  • 2_issuer_Intermediate.crt

image

The issue here is that when a client initiates a SSL handshake, IIS gives the client all certificates in the certificate path, not only the server certificate. If the Issuing CA is not present in the local store (on the IIS server) it does not sent it to the client. It doesn’t matter that both IIS and the client easily could locate the Intermediate certificate using the AIA attribute in the server certificate.

Note that no changes needs to be made on clients and that the warning it not because the certificate is not trusted, it is that the client cannot find the intermediate CA certificate and therefore cannot identify what Root CA certificate to verify trust for. When it is added to the IIS and given to the client at the SSL handshake, the client “realize” that they trusted the server certificate all along.  Smile

Phew, this became a much bigger blog post than I first imagined. I hope you found it useful!

=== Update 2016-06-03 ===

Some services has issues with the certificate, such as TMG (says Incorrect Key Type) and Exchange OWA (you are returned to the login page when logging in).

Assuming that you made the private key exportable in the first place you can solve this by exporting the certificate and it’s private key to a pfx, import that pfx into Firefox’s certificate store and then do a backup of that certificate in Firefox. This will create a new pfx, that when imported will work with TMG and Exchange OWA.

Note that the issues are not because the certificate is CNG, which many seems to suggest. Remember that we chose Legacy key a few steps up (which is the same as CSP) and not a CNG key:

image

Posted in Certificates, PKI | Tagged , , , | Leave a comment

My Advanced Threat Analytics session (in swedish)

About a month ago I gave a talk about Microsoft Advanced Threat Analytics (ATA) at TechX, a Microsoft event here in Sweden.

The session is now posted on YouTube and available for everyone to see. Please note that the talk is given in swedish.

Unfortunately the first few minutes – where I talked about the history of ATA – was not recorded.

If you only want to see the ATA demos, jump directly to 23:30.

https://youtu.be/FzY73rxDtfw

image

Posted in Okategoriserade | Leave a comment

Installing CA via PowerShell : “-Whatif” not working

I just installed a CA server for testing, and noticed something strange.

First I installed the binaries with the cmdlet Add-WindowsFeature, without any issues:

image

When I was about to install and configure the CA role with the Install-AdcsCertificationAuthority cmdlet, I first wanted to see what the default values would be for parameters like CAType, KeyLength and ValidityPeriod, if I only supplied CACommonName and HashAlgorithmName.

According the the technet article about the Install-AdcsCertificationAuthority cmdlet (see here), I should be able to use -Whatif:

image

So I simply added “–Whatif” at the end:

image

I never saw any values in the output, but I figured that “ErrorId = 0” was a good sign and that the command at least would work as expected when I ran it without –Whatif.

I then removed “Root” from the CACommonName and ran the command again, this time without -whatif, but lo and behold, I got an error message saying that the CA was already installed!

image

At first I thought that WhatIf might be case sensitive, but it’s not:

image

So be careful when using -Whatif together with Install-AdcsCertificationAuthority.

Posted in Okategoriserade | Leave a comment

Require SSL on NDES admin site via PowerShell

Best Practices from Microsoft when deploying Network Device Enrollment Service (available here) states:

“Always set up the administrator site with SSL-only configuration. (Disable http access to this site.)”

This is to protect the sensitive One Time Passwords that are transmitted between the server and the client’s browser.

The path that you want to enable SSL requirement for is:
https://<FQDN of NDES Server>/certsrv/mscep_admin

Note that the path for NDES certificate requests should not be SSL enabled:
https://<FQDN of NDES Server>/certsrv/mscep/mscep.dll

If you have installed both the Network Device Enrollment Service and the Certificate Authority Web Enrollment role services, the virtual directory certsrv/mscep_admin is available in IIS Manager:

image

You can easily enable SSL via the GUI, here is one of many guides explaining how.

However, if you only install the Network Device Enrollment Service role service (and do not want to add Certificate Authority Web Enrollment), the virtual directory certsrv is not created in IIS:

image

This means that you cannot enable SSL requirement via the IIS Manager GUI.

The web server still answers requests to this path, and you can see the virtual paths in the Applications view:

image

But unfortunately you cannot configure SSL requirement in the Applications view.

The solution? Use PowerShell and the sslFlags setting.

To see the current SSL configuration on the CertSrv/mscep_admin site:

Get-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags”

 

To require SSL for the CertSrv/mscep_admin site:

 

Set-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags” -value “Ssl”

 

Note that the commands above do not include the name of the server, so they do not have to be modified to work in your NDES implementation (unless you manually chose another website than Default Web Site for NDES). Also note that you need a valid certificate installed on the server before requiring SSL to avoid error messages in the browser.

Here is the output when the commands are executed:

clip_image001

Here is the result when accessing the NDES admin page over http, after enabling SSL requirement:

 

image

Accessing it via https works:

image

The path for NDES certificate requests still works over http:

image

To revert back to the default configuration:

 

Set-WebConfigurationProperty -pspath ‘MACHINE/WEBROOT/APPHOST’ -location ‘Default Web Site/CertSrv/mscep_admin’ -filter “system.webServer/security/access” -name “sslFlags” -value “None”

Posted in CA, Certificates, NDES, PKI, SCEP | Tagged , , , | 3 Comments

Forced password change at next logon and RDP

If your AD account has the “User must change password at next logon” option enabled:

clip_image001

and you try to logon to a RDP session (with correct credentials):

image

you might encounter this error message:

image
“You must change your password before logging on the first time. Please update your password or contact your system administrator or technical support.”

This is a classic catch 22 issue: You have to logon to change you password, but you cannot logon until you’ve changed you password.

If you have access to a “normal” network connected Windows client you can change the password that way, but what if you only have RDP access?

Client side

Well, if the server allows it, you can temporary disable “Credential Security Support Provider (CredSSP)” in the RPD client. This disables Network Layer Authentication, the pre-RPD-connection authentication, and therefore enables you to change your password via RDP. CredSSP is enabled by default in the RDP client on Windows Vista and forward.

There is no option to disable CredSSP in the RDP client, so here is how you have to do it:

  • Start mstsc.exe
  • Click Show Options
  • Click Save As

image

  • Call it ChangePassword.rpd (or anything you’d like, but avoid the name Default.rdp)
  • Open the saved ChangePassword.rpd in Notepad
  • Add a new row at the end with the following text:
    enablecredsspsupport:i:0

clip_image003

  • Save the rdp file
  • Double-click the rdp file
  • Enter the name/IP of a domain connected computer with RDP enabled

Instead of the local Windows Security prompt (the second image in the blog post) you should see a Windows Logon screen on the remote computer (if not, read on anyway):

image

If the account you log on with at this point has the “User must change password at next logon” option enabled, you get notified about that:

image

By clicking OK you get the possibility to change the password (yay!):

image

After changing the password you get confirmation about the change:

image´

Clicking OK logs you in.

In fact, you do not need to have access to sign in through RDP, in that case this shows up, but only after you successfully changed your password:

image

Delete the ChangePassword.rdp file when you are done (or at least do not use it until you are forced to change your password again), since disabling CredSSP lowers the security of RDP connections.

If the server requires CredSSP

If the server does not allow you to disable Credential Security Support Provider, you get this error message when connecting:

image

In that case, try connecting using the FQDN (DC01.tomdemo.se and not only DC01) or connect to other servers that might allow you to disable CredSSP. As I mentioned above, you don’t have to have access to actually logon to the server.

Server side

You can also disable CredSSP on the server side, but since that lowers the security on all RDP connections to that server it is not recommended.

If you chose to do this anyway, you do it either by de-selecting “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)” in System Properties:

image

Or if you run the Terminal Server Role:

  • Open Terminal Server Configuration
  • Open RDP-Tcp configuration page
  • On the General tab, set the Security Layer to RDP Security Layer

image

Note that if you already have an existing access to a server (with the account you need to change the password with) you could just change your password in that session by pressing Ctrl-Alt-Del (or Ctrl-Alt-End in an RDP connection) and choosing Change a password:

image

I hope this post helped.

Posted in Okategoriserade | 15 Comments

Keep your OneDrive storage size

A while back Microsoft announced that the storage in the free version of OneDrive will be decreased from 15 GB to only 5 GB. The bonus storage of 15 GB extra when activating Camera Roll Backup in OneDrive will also be removed.

This was not well received by users, and Microsoft is now offering users to to keep the old storage size and the camera bonus when the new limitations are rolled out.

All you have to do is go to this link:
https://preview.onedrive.com/bonus/

After you have logged in and authorized the application called preview.onedrive.com, you should see this message:

image

This offer must be redeemed before January 31 2016.

Note that this tip is about the consumer version called OneDrive, not the enterprise version, called OneDrive for Business.

Posted in Okategoriserade | Leave a comment

AppLocker Bypass Checker

One of the Default Rules in AppLocker allows everyone to execute everything in the folder C:\Windows:

image

The reasoning behind this must have been that a non-admin Windows-user should not have write permissions anywhere in that folder. But as it turns out that is not the case.

I wrote a PowerShell script that tries to copy an executable to every folder in Windows and (if the copy succeeds) tries to execute it. At the end it will show what folders are at risk for AppLocker bypass and must be managed accordingly. Preferably by creating exceptions in the default Allow Rule or by adding a new Deny Rule that includes these folders. I would not recommend messing with the NTFS permissions on folders in C:\Windows (or where your %systemroot% is located).

I chose mstsc.exe as the executable (it’s short for Microsoft Terminal Services Client), since it is small, built-in and can run multiple instances. During the test you will see instances of this showing up:

image

Do not close them manually, as they are enumerated by the script at the end. They will be closed automatically by the script.

Remember to run the script as a user. Admins have another Default Rule that enables them to run anything anywhere. And if you wanted to bypass AppLocker as an admin (in case the default Admin Rule was removed) you could just stop the service “Application Identity” that AppLocker relies on to function properly.

You might have an Execution Policy that prevents you from running the script. In that case you have (at least) two simple options:

  1. Open the script in Windows PowerShell ISE (by right-clicking the script and choosing Edit), select the entire script with Crtl-A and then press F8 to run the selected code.
     
  2. Run Powershell with the option “-ExecutionPolicy Bypass”:
    image

This is also a good reminder that Execution Policy is NOT a security feature. It is meant to prevent accidental execution of scripts. Here are 13 additional ways to bypass it: https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

I did notice that I got these warnings when bypassing Execution Policy (but not when changing the Execution Policy to RemoteSigned). Just ignore them as well:

image

You will see some errors when the script could copy a file, but not execute it:image
You can ignore these too.

At the end you should see something like this (in this case it was run on a Windows 10 build 10565):

image

Download the script here:
http://go.mssec.se/AppLockerBC

Don’t forget you might need to validate all the Program Files subfolders in a similar fashion if you keep that Default Rule.

Standard Disclaimer: I am NOT a coder. I am not responsible for what this script does. Do a code audit of the script if you run it in a sensitive environment.

Please leave any feedback you have as a comment to this post.

Posted in AppLocker | 9 Comments

How does your browser react to certificate errors?

Sometimes I need to see how my browser (or some other device) reacts to different certificate issues. Examples of issues are:

  • Expired certificate
  • Revoked certificate
  • Self-signed certificate
  • Certificates with wrong subject
  • Mixed content (http content on a https web page)

With the ongoing deprecation of SHA1, other interesting test cases are:

  • Certificate signed with SHA1 that expires in 2016
  • Certificate signed with SHA1 that expires in 2017

Instead of spending time on setting up these scenarios myself I use the following site:

https://badssl.com/

It works on any device that has a web browser. Here is a screenshot from Safari on my iPhone:

20151006_115352000_iOS

Clicking a button/link will redirect you to a website that has a certificate with that specific error.

Here are screenshots where the name of the site does not match the name in the certificate (the wrong.host button):

Edge

image

Internet Explorer 11

image

Chrome v45

image

For some reason they to not have a revoked certificate, so for testing that issue I use Steve Gibson’s test site at the address https://revoked.grc.com/

Posted in Okategoriserade | Leave a comment

Quick access to the Certificate snap-ins

image

Are you also opening the local certificate snap-ins by first running mmc.exe and then adding the Certificate snap-ins manually? I’ve done that sooo many times that I’ve gotten pretty fast at it.

A faster way is to type certmgr.msc for User Certificates and certlm.msc for Computer Certificates (certlm.msc does not work on Windows 7 or older).

But did you know that from Windows 8 there is an even faster way?

Just press the Windows key and type certi

This is how it looks like on Windows 10 (build 10074):

image

Note that on some OS versions typing just cer or cert also shows them both, but I have found that typing certi always show both of them. This is for example how it looks like on windows 8.1, typing just cert:

image

But when I type certi I see both User and Computer:

image

I realize that this only saves you a couple of seconds, but wasted seconds adds up in the long run  Ler

Posted in Certificates, PKI | Tagged , , , | Leave a comment