Adding SAN (Subject Alternative Name” into “Additional Attributes” field on a Microsoft Certificate Authority certificate request form does not generate a certificate with a SAN entry

Problem

You’ve completed the process of creating a new keystore with a CSR from the Portecle utility:

http://portecle.sourceforge.net/

Since the Portecle utility does not provide the feature to include SAN entries:

https://www.sslsupportdesk.com/portecle-advanced-keystore-creation-and-manipulation-tool/

This isn’t usually a problem because it is possible to add SAN entries in the Additional Attributes field when submitting the CSR to a Microsoft Certificate Authority server as described here:

How to add a subject alternative name to a secure LDAP certificate
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate

An example of the format of the string to include is:

san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com

You proceed to submit the request:

… but notice that the generated certificate does not include a SAN entry.

Solution

One of the reasons why performing the above would not generate a certificate that includes a SAN entry is if the issuance policy of the Microsoft CA is not configured to accept the Subject Alternative Name(s) attribute via the CA Web enrollment page.  To correct this, execute the following command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Once the above command is executed, stop and start the certificate authority with:

net stop certsvc
net start certsvc

Proceed to use the CA web enrollment page to generate the certificate with the SAN entry.

---------------------------------------------------------------------------------------------------------------------------

Security Concerns:

Note that as per the following Microsoft article:

https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

It is not recommended to enable the acceptance of the SAN attribute for the CA Web enrollment page so please review the Security best practices for allowing SANs in certificates section in the article above to be aware of the security concerns.

Attempting to assign a certificate to the Lync Server 2013 services via the Certificate Wizard console fails and generates the error message: “Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.”

Problem

You’ve created a new certificate for your Lync Server 2013 services and attempt to assign it to Server default and Web services internal:

However, the assignment fails and the following error message is displayed:

Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.

Solution

One of the reasons why the certificate assignment would fail with the error message above is if an administrator or group policy has removed the administrators group from the Lync Server’s Manage auditing and security log policy as shown in the following screenshot:

To correct the problem, simply grant the local administrators group the Manage auditing and security log policy permissions:

You should be able to assign certificates to Lync Server 2013 services once the above has been completed.

A recent change to the SQL authentication account for an SRM database causes the VMware vCenter Site Recovery Manager Server to no longer start

Problem

You’ve recently had to reset the password to the SQL authentication account used by your VMware vCenter Site Recovery Manager to connect to the SRM database so you proceed to update the ODBC System DSN as such:

However, attempting to start the VMware vCenter Site Recovery Manager service fails with the following error:

The VMware vCenter Site Recovery Manager Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.

The following event error is logged in the event logs after the failed start:

Log Name: Application

Source: vmware-dr

Event ID: 3

Level: Error

DBManager error: Could not initialize Vdb connection: ODBC error: (28000) - [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'vmware'.

Attempting to modify the installation of SRM will display the following error:

A database error has occurred.

Solution

The reason why the service is unable to start is because other than updating the ODBC System DSN, you’ll also need to use one of the steps in the following KB to update the password:

Migrating an SRM server to run on a different host (1008426)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008426

The step required to get the environment in this example up is #7:

Run the installcreds.exe utility to register account credentials on the new host with the old DSN:
installcreds.exe -key db:new_SRM_DSN -u sql_admin_user
The installcreds.exe utility can be found in the bin directory of the SRM installation:
C:\Program Files\VMware\VMware Site Recovery Manager\bin

The following is an example of the executed command:

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>installcreds.exe -key db:SRMDR -u vmware
VMware internal use only. This program is intended for use only by the SRM installer.
Enter Password:
Installed new credentials for db:SRMDR

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>

The service should now start as the password has been updated:

Update: Securing Citrix NetScaler VPX to score A+ rating on SSL Labs

Those who have used my previous blog post:

Securing Citrix NetScaler VPX to score A+ rating on SSL Labs
http://terenceluk.blogspot.com/2016/06/securing-citrix-netscaler-vpx-to-score.html

… to score an A+ on Qualys SSL Labs (https://www.ssllabs.com/ssltest/) may have noticed that they are now scoring an A- due to some minor changes to the criteria. 

There is no support for secure renegotiation. Grade reduced to A-. MORE INFO »

The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. MORE INFO »

The required changes to the configuration are minimal so this blog post serves to demonstrate the tweaks required to bring the score back to an A+.

The version of the NetScaler VPX I’ll be using for this demonstration is:

NS11.1: Build 49.16.nc

Step #1 – Confirm that the SSL certificate used is SHA2/SHA256 signature

Ensure that the SSL certificate used to secure the site uses the SHA2/SHA256 signature for both the root and intermediate.

Step #2 – Confirm that SSVLv3 is disabled and TLSv12 is enabled

With the appropriate certificate assigned begin by ensuring that SSLv3 is disabled and TLSv12 is enabled for the SSL Parameters of the virtual server:

Step #3 – Update Custom Ciphers

The ciphers listed in my previous post is outdated so proceed to remove the existing configuration or appending the new ciphers in, or creating a new one with the following ciphers:

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-256-SHA384
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES256-SHA
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES256-GCM-SHA384
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-AES-256-CBC-SHA
TLS1-AES-128-CBC-SHA
SSL3-DES-CBC3-SHA

The following command can be used to create a new custom cipher with the required ciphers:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName SSL3-DES-CBC3-SHA

With the custom cipher created, ensure that the virtual server is configured to use it:

Step #4 – Configure Deny SSL Renegotiation to FRONTEND_CLIENT

Navigate to Traffic Management > SSL > Change advanced SSL settings:

Change the Deny SSL Renegotiation setting from ALL to FRONTEND_CLIENT:

Alternatively, the following command can be executed to change the configuration:

set ssl parameter -denySSLReneg FRONTEND_CLIENT

-------------------------------------------------------------------------------------------------------------------------

You should now score an A+ with the adjustments listed above configured:

Remember to save the configuration!