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.
18 comments:
Thanks for the fix!
this is like the first comment ever. never usually do this.
not this time.
thanks a lot, Terence!
Thanks! Been fighting this for hours!
Thank you!
It's funny: I've done this at least 2 or 3 times in the past, and yet forgot about it. :)
But, a quick scan of your post had me going in no time. Thanks!
I used your trick and it worked well ! Thx!
DO NOT USE THIS "TRICK" ON AN ENTERPRISE CA!!!
The CORRECT method is to NOT to enable (EDITF_ATTRIBUTESUBJECTALTNAME2) Windows Server 2008 and up servers. This is when you want to submit SANS by using *request attributes*. The more secure method is to submit a request with SANs in the request *Extensions*. To do this on a windows CA, you do is create an INF file with the SAN names in the [Extensions] section and use Certreq to generate the actual request.
For example:
------Request.INF---
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=www01.fabrikam.com" ; Remove to use an empty Subject name.
;Because SSL/TLS does not require a Subject name when a SAN extension is included, the certificate Subject name can be empty.
;If you are using another protocol, verify the certificate requirements.
EncipherOnly = FALSE ; Only for Windows Server 2003 and Windows XP. Remove for all other client operating system versions.
Exportable = FALSE ; TRUE = Private key is exportable
KeyLength = 2048 ; Valid key sizes: 1024, 2048, 4096, 8192, 16384
KeySpec = 1 ; Key Exchange – Required for encryption
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10 ; or CMC.
[Extensions]
; SANs can be included in the Extensions section by using the following text format. Note 2.5.29.17 is the OID for a SAN extension.
2.5.29.17 = "{text}"
_continue_ = "dns=www01.fabrikam.com&"
_continue_ = "dns=webserver1.domain.fabrikam.com&"
----end of INF file---
For operating systems prior to 2008, you can include SANs in the [Extensions] section by using a base64 formatted string. Per the above INF file, replace Extensions with the below:
-----
[Extensions]
2.5.29.17=MCaCEnd3dzAxLmZhYnJpa2FtLmNvbYIQd3d3LmZhYnJpa2FtLmNvbQ==
--------
To format the base64 SAN request, there's a script on this page. But you should not have pre-2008 servers now anyway.
Once you've correctly formatted your SAN INF request file, you use Certreq.exe to create the actual REQ file for submitting to the CA.
Certreq can submit the request and retrieve the cert from the CA, or you can copy and paste the REQ file contents into a custom certificate request on the CA website. The linked page has a fuller version of the INF template and instructions for your perusal.
Thanks for the fix.
My issue got fix with this article.
Thanks for posting -- very helpful.
The article you link to regarding not applying this to an enterprise CA is from 2013. Given the new requirements for modern browsers regarding SAN use, I'd make the case that this is probably OK to enable, assuming you have proper controls around who can submit and approvals are configured / required.
my .02
Thank you so much for your contribution, you make internet even better!
Really helpful thank you very much! Anyone that has their firewall setup properly shouldn't be afraid of making this change imo
This is very helpful, I spent couple day googling, finally found this instruction.
Life saver!!!
Many thanks
This is very helpful. Thank you very much for the solution.
Thanks very much. This helped me.
^ Just to emphasize the message above, modern browsers REQUIRE a SAN in the cert.
Many appliances/devices generate a CSR for you that DOES not include a SAN in the request.
Often these systems/devices won't let you export/import the private key, rightly, so that it remains secure on the device. Therefore generating a cert request with inf and defining SANs wont work, because you can't touch the private key on the device and you'd have to export the private key with the new cert.
Bear in mind public CAs add a SAN to cert upon signing as standard, so THEY are adding SANs at signing vs making you submit them in the request.
Also, claiming that it is more secure to do an INF request ignores the fact that then you are manually handling the private key. Much better to keep it on the client and restrict certificate enrollment privileges themselves to trusted individuals with change control.
So yeah, adding SANs upon signing is fine, as long as you have actually secured your PKI and restricted it to authorized individuals only, which is much more important than the SAN policy in any case.
Gay sex in the bed
I really tried to stop microsoft teams from showing away and can anyone tell how do i stop microsoft teams from showing away?
@Thomas Strand I tried this but I am still unable to generate the certificate with a SAN
Post a Comment