Where does RDP/MSTSC cache OCSP responses on Windows 10?
I'm testing an OCSP responder implementation with remote desktop on a Windows 10 system (foo), connecting to another Windows 10 system (bar). The OCSP responder works, i.e., the remote desktop client on foo:
Validates bar's certificate
Gets the OCSP URI from that certificate
Receives a signed response from its query to the OCSP responder
Connects to bar without any certificate warnings
Now I want to clear the revocation cache to continue my testing, but I can't figure out how to do so. I've tried various certutil commands and rebooting foo without any luck, e.g.:
certutil -setreg chain\ChainCacheResyncFiletime #now
certutil -urlcache ocsp delete
Reference: Delete local CRL cache in Windows | Microsoft Security Solutions
I couldn't find any definitive documentation from Microsoft on the matter, but as far as I can tell from my testing, the RDP client doesn't request/cache OCSP responses at all.
Rather, the RDP server will:
Query its certificate's status from the OCSP responder;
Cache the response, which seems to be tied to the remote desktop service state; and
Present the certificate's status to the client during the TLS handshake, i.e., OCSP stapling.
To clear the cached/stapled OCSP response on the RDP server, restart the Remote Desktop Services service (TermService).
You can test this yourself by performing a packet capture during the RDP session setup; the TLS Server Hello handshake should include a Certificate Status component.
Oddly enough, testing RDP with openssl s_client -status -connect ... doesn't show the OCSP response where testing a web server does. I think this is what threw me off initially. For example, testing digicert.com with OpenSSL shows the stapled OCSP response.
openssl s_client -status -connect digicert.com:443
Related
I have written a basic TLS client for use in embedded systems (written in C). It uses TLS1.2, and it works great in 90% of situations. I have it working fine for HTTPS, and also have it working with various FTP servers using implicit and explicit FTPS. This week I've encountered an issue when using it with Cerberus FTP and proftpd though. TLS handshake goes through absolutely fine when opening the control channel on port 21, but when using passive mode and opening the passive port, my client sends the TLS Client hello (and I can see the server reply with a TCP ACK), but the FTP server never replies with a Server Hello. Does anyone know of a reason why that might be?-I'm guessing that there is something different in the way Cerberus and ProFTPd have implemented TLS that my client doesn't cater to. My client hello on both connections is identical (apart from port number in tcp headers) and I am not reusing the session data. I don't have this issue when testing against vsftpd or filezilla servers.
Found the reason for the lack of response, and it's an interesting one if anyone is ever writing their own FTP Client and need to use FTPS with it. The FTP Client I had written issued the PASV command, and then immediately opened the data channel port before then issuing the STOR command on the control channel. This behaviour is fine for all FTP servers when using un-encrypted FTP. However, as I discovered, you have to beware when using TLS. With proftpd and cerberus FTP, the FTP server doesn't seem to attach a listener to that port until you issue the STOR command (or equivalent), so it won't negotiate TLS on that port until you've issued the command, whereas other FTP servers like vsftpd and filezilla are happy to negotiate TLS as soon as the port is opened. SO the solution was to open the port after sending the STOR command.
I am working on a small application on an embedded platform which has to send some classified information to a server. This connection to the server is encrypted using SSL. The encryption is tunneled trough a proxy - in this case a Zentyal proxy. The embedded application is written in C and the connectivity part is done with wolfssl and lwip.
The application works fine with Zentyal 5.1. But recently the proxy server was updated to 6.1 and now the connection is falling all the time. Debugging the issue, I have found the problem occurs when the application ask the server for a tunnel connection. What I see happening is that the application sends the CONNECT request to the proxy ...
... to which the the proxy answers with a 200 Connection Established.
But after that packet is received the proxy send another message with Proxy-Coneection:Close. Whith has the effect that the connection is shut down before the SSL handshake.
I have tried different configuration in the Zentyal (transparent proxy enable, disable cache, etc.) but the error remains the same. Also, I have added different HTTP headers like proxy-connection: Keep alive. But the connection is still being closed.
Maybe this is a problem with the 6.1 version. I have tried looking through the change log but there is no reference to any change in the processing of the connect request. Neither are there any known problems related to the way the connect is being handled.
Any advice?
I'm setup a new Active Directory on my Windows server (Windows server 2008 R2).
And it is working fine for port 389. I need use LDAPS protocol to modify password from other system.
According to this post https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority, the only thing is import a certificate for enable LDAPS.
But when I imported the SSL certificate and restart the domain controller, I cannot see port 636 is opening.
My SSL certificate is issued by GeoTrust, and using for website. The website domain same with AD DS FQDN. I'm not sure is it OK.
How can I check what's the problem ?
I would start by check the certificate enhanced key usage, make sure the Server Authentication (1.3.6.1.5.5.7.3.1) are in the enhanced key usage. This can be done by open the certificate and click on "details" tab and scroll to "Enhanced Key Usage"
On the domain controller open an MMC and add certificate snap-in with local computer and verify if the certificate is in the personal certificates. If the certificate is there you can double-click on the certificate under General tab did you see a line at the bottom stating "You have a private key that corresponds to this certificate."?
When you say "I cannon see port 636 is opening" how are you doing about doing that? Did you run netstat on the domain controller to see if the server is listing?
syntax: netstat -an | find "636"
-a display connection and listening ports
-n display ip
find "636" is to filter for port 636. Because this is a domain controller you will have a lot of connections.
Also, if you have access to openssl you can try the following
syntax: openssl s_client -connect domain_controller_ip:636
if the certificate configure properly and the domain is listening to port 636/tcp. you will get the certificate information return.
The problem is certificate not match.
My AD domain is xyz.com, I thought my certificate Common Name should be xyz.com, it's wrong.
The right Common Name of the certificate should be Full computer name or Computer name+Domain. My computer name is ad, then I need the Common Name is ad.xyz.com of the certificate.
Using information from some consultants about 2 years ago we set up a SQL Server 2012 box to always have an encrypted connection (at least we thought so). A week ago the SSL certificate expired and everything continues to work fine which is puzzling.
We forced encryption by doing the following:
Obtain an SSL certificate and install it on the SQL Server via MMC. Explicit instructions for this step are here.
Open SQL Server Configuration Manger and expand the SQL Server Network Configuration node in the left pane.
Right click Protocols for MSSQLServer and choose properties.
Go to Certificate tab and choose the installed SSL cert from the drop down.
Go to the Flags tab and set force encryption to Yes.
Now, since the SSL cert expired, there is no longer any cert selected in the drop down when I visit step 3 above. However, I put WireShark on the DB server and use SSMS to request some data. The TDS (Tabular Data Stream) packets are still encrypted? When I put WireShark on a different DB Server I set ForceEncryption to NO, those TDS packets are not encrypted as expected.
So my questions are:
How are the TDS packets still encrypted if the cert is expired?
Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
1)How are the TDS packets still encrypted if the cert is expired?
you don't need a valid certificate in order to encrypt, you can still encrypt using an expired certificate.
2)Even when the cert was valid, why didn't I have to select Options > Encrypt Connection to connect to my encrypted DB server? I thought setting ForceEncryption=Yes required ALL client connections to specify Encrypt in their connection string (or the SSMS checkbox)?
Do not enable the Force Protocol Encryption option on both the client and the server,
if you enabled force encryption on SQL server you don't need to do it on any client-side
3)If Web APIs are the only method of accessing my DB, and they do so over SSL, is it even necessary to encrypt the SQL Protocol?
To enable SSL you need the certificate to be installed on SQL server so in order to access the DBusing SSL you are doing the same job.
Thank you
I am trying to create a NTP client-server setup using Autokey authentication for server validations. I have followed the instruction on link http://support.ntp.org/bin/view/Support/ConfiguringAutokey to setup client and server on NTP 4.2.6 . The setup I had created is working in some unexpected manner.
I had created server and client certificates using ntp-keygen as mentioned in the above link. I have edited the client's ntp.conf to use autokey to authenticate server. As mentioned in the above link, I have to copy the server key to client for authentication to work, but while testing I have found that client is able to verify the server even if I do not copy the server certificate on the client. The result for "ntpq -c as" show auth field "ok" for the server and ntpq -c "rv 0 certs" shows the server certificate bindings.
Can someone explain me why NTP is able to verify server without copying the server certificate on client ?
If this is not the expected behavior, what are the changes I have to make in the configuration to get it working correctly.
See
CVE-2014-9295
Just don't do it