Just another IT blog
You might think the place to make the change would be in a certificate template but that is not the case. It looks like the default hash algorithm is stored in the registry and can be changed with certutil.
Run this directly on your CA as administrator:
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
Then restart your Certificate service:
net stop CertSvc
net start CertSvc
Freshly issues certificates should now have a SHA256 hash instead of an old depricated SHA1.
sometimes you need to quickly check an endpoint or site and grab the dates/ when a certificate expires. Of course you could just log onto the server in question and inspect the certificate or try and coax your browser into letting you view the certificate properties. That said this is often quicker and could be handy as part of a larger script, check or automation piece.
This quick one liner will show us when the certificate on centos.org is valid for, just change the site name and port to that of the endpoint you want to check.
[root@tst-sh01~]# echo | openssl s_client -connect centos.org:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jul 29 00:00:00 2014 GMT
notAfter=Aug 2 12:00:00 2017 GMT
Connecting to a remote desktop server fails and the server logs and error with the source: Schannel; Event ID 36888. Schannel errors are usually down to problems with SSL and certificates. This case is no different. Simply run mmc.exe and go to “file” then “add/remove snap-ins” and select “certificates” and choose “computer account”
Next navigate to remote desktop > Certificates and highlight the certificate with the computer name listed in the “issued to” and “issued by” field and delete it.
Once the certificate is deleted simply disable then re-enable remote desktop services and restart the remote desktop service service. This should regenerate the certificate and you should now be able to connect to your remote desktop server again.
It is becoming the norm to use larger private key sizes with certificates and while trying to generate a new request on a windows 2003 box I found my self unable to change the key size at all, it was greyed out. After a bit of head scratching I noticed all the cryptographic service providers were ticked.
After changing the tick boxes so that only the “RSA,Microsoft Software Key Storage Provider” is ticked the option becomes available and the key size can be customized.
If (like me) you are generating some CSRs to be used on a forefront threat management gateway or similar don’t forget to make the private key exportable so later on you can export it to the TMG server.
Update: This is still true for modern server versions such as 2012 R2 and 2016.
Exchange 2010 includes a certificate wizard to help you generate a certificate request without having to manually type each of the fields and make your own requests in the certificates MMC. Unfortunately you then cannot complete the request using the Microsoft certification authority as you get an error message. Normally this error is along the likes of “Bad TAG” or “Certificate not issued (Incomplete)”
Credits to Laurance at Dell for the solution to this particular error which turned out to be that the CSR generated by Exchange 2010 is in Unicode format and certificate services is expecting it to be in ANSI. Simply open the request file in notepad and save it in ANSI file format. Make sure to surround the entire file name in quotes to preserve the file extension and change the file name from the original.
Now you will get a new error because exchange hasn’t included a certificate template along with the request and certificate services needs to know which template to use. Open a CMD window (as admin or you will get another error) and type in the following: certreq -attrib “CertificateTemplate:WebServer” you should then be prompted to browse for your request file and if all is well for a place to save the completed certificate. Then you can use this certificate file to complete the pending request with the exchange 2010 certificate wizard.
I have recently been working on implementing a number of new exchange 2010 servers and had an issue where some mail was getting stuck in a queue. For example messages from mailboxes on Server B to mailboxes on Server A end up in one of Server B’s queues called “SMTP Relay to Remote Active Directory Site.” and the last error is 451 4.4.0 Primary Target IP address responded with: “421 4.4.2 Connection dropped.
Now I knew it wasn’t a firewall or network issue as I could telnet into port 25 from each of the servers to each other and sending email in this way also worked. Curiously I couldn’t see anything in the event logs either. The Mail Flow Troubleshooter gives the message ”It appears that the SMTP service and SMTP instance(s) on server A are started but the port did not respond. Check if there are any network errors or hung services.” Also gives “Error submitting mail.” The issue remains after a service and server restart.
The resolution for me was to re-assign the original self signed certificate to the SMTP service instead of the 3rd party CA signed certificate we were using for OWA. (even though it had a valid SAN for the internal FQDN) and then restart the transport service on server A. Once the SMTP service was using the self signed cert all the queued mail was delivered. I hope this helps someone else out there struggling with this issue.