We are currently using Identity Server 3 and want to upgrade to Identity Server 4.
We recently did a Penetration Test for a large client of ours and they picked up that we allowed the TLS_RSA_WITH_3DES_EDE_CBC_SHA cypher suite. Which is an insecure Cipher Suite with known vulnerabilities.
When we disallowed it, then Identity Server 3 stopped working.
Is there a way to get IdentityServer3 to work when disabling this cipher suite?
Our certificate is correct and meets the requirements.
Will Identity Server 4 work if we disallow it? Or will it give the same problem.
The error we got was the following:
The Client and Server cannot communicate, because they do not possess a common algorithm.
After some investigation, as indicated by leastprivilege, it was a microsoft issue.
When using .net4.5 and below they do not use tls1.2 by default and always revert to tls1.1.
So you if you are using .net4.5 then you need to tell it to use tls1.2 by setting the registry settings indicated by this article:
https://techsupport.osisoft.com/Troubleshooting/KB/KB01625
Once I configured those registry settings, then everything worked fine using tls1.2.
Related
I created a simple .NET 7.0 app with SQL Server and if I use the default "localdb" or even after I change it to a "network server", I get the error below:
The certificate chain was issued by an authority that is not trusted.
My connection string is:
mysqlserver.com;Initial Catalog=db_database;User Id=db_admin;Password=pass123;Persist Security Info=True;Encrypt=true;TrustServerCertificate=yes
What am I doing wrong?
PS: With the above connection string I can scaffold the database.
This is a breaking change in EF Core 7.0 as noted here: https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/breaking-changes
You have two options. Option 1: Install a valid certificate on the server https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-sql-server-encryption?view=sql-server-ver16
Option 2: You need to add TrustServerCertificate to true or Encrypt=False. The downside with this option is you may leave the server in a potentially insecure state.
mysqlserver.com;Initial Catalog=db_database;User Id=db_admin;Password=pass123;Persist Security Info=True;Encrypt=true;TrustServerCertificate=true;
The easy fix is to set Encrypt=False; Please look at the link in the comment above. I ran across this a while back. A breaking change was introduced in Microsoft.Data.SqlClient. While making it more secure by default, the idea is that you now have to implicitly opt into a less secure connection by turning off Encrypt, which in the prior releases defaulted to false, if not set.
At first, please note that I am aware that this question has already been asked several times. However, the accepted (and non-accepted) solutions given so far did not work in my case, so something substantial must have changed since then, which hopefully justifies asking again.
Having said this:
I am currently trying to upgrade an Access 2010 .adp application to Access 2019 .accdb. The application includes a lot of VBA code which uses ADO objects to connect with and operate on Microsoft SQL server (currently: 2008 R2, but will be upgraded soon).
I'd like to keep the most part of the code, which means to stick with ADO, so the way to go is the new OleDB SQL server driver (which has been undeprecated / newly released in 2018). The SQL server runs on another machine than my client application.
I am not able to establish a connection to SQL server from VBA. When executing the following code snippet
Dim cnTemp As Connection
Set cnTemp = New Connection
cnTemp.CursorLocation = adUseServer
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;Authentication=SqlPassword;User ID=sa;Password=secret;DataTypeCompatibility=80;"
I get the following error when the last line is executed:
SSL Provider: The certificate chain was issued by an authority which is not trusted.
OK, no problem, after all we have found all the other questions dealing with the same issue, all suggesting the same solution: Add Trust Server Certificate=True; to the connection string.
Well, tried that, but -to my surprise- still the same situation. Then I tried some other variants like TrustServerCertificate=True; or using true instead of True, but to no avail. I also tried adding Use Encryption for Data=True; which didn't help either (that could be expected). Furthermore, I tried some of the snippets I had found when researching the problem, but which are not documented by Microsoft as being valid in ADO connection strings (like Encrypt=true or Trusted_Connection=true;); of course, that made the situation worse, raising other error messages.
I have understood that I could solve that problem by putting the SQL server certificate into the client's trusted root certificate store, or by having SQL server use a certificate which has been issued by a known, trusted CA (e.g. Let's Encrypt).
However, I'd strongly like to know why adding Trust Server Certificate=true; to my connection string does not make the error go away and what I have to put in there to disable certificate validation (and by the way, I would be grateful if we wouldn't start a discussion about why this would be bad; this is just development and testing in a trusted, closed network, and I am aware of possible risks).
The reason TrustServerCertificate=True in the connection string is not honored is twofold. One is that it isn't a valid ADO classic (ADODB) connection string keyword. According to the ActiveX Data Objects (ADO) Connection String Keywords documentation, the keyword/value pair should be Trust Server Certificate=True (note spaces). The keyword is ignored entirely without the spaces and not trusted as a result.
However, this change alone will not trust the certificate because of the Authentication-SqlPassword specification. When the Authentication keyword is specified, the documentation footnote calls out:
To improve security, encryption and certificate validation behavior is
modified when using Authentication/Access Token initialization
properties or their corresponding connection string keywords. For details, see Encryption and certificate validation link.
The referenced link includes this important note:
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So even with Trust Server Certificate=True, the cert will be validated when this registry value is set to 0.
One solution is to simply remove the Authentication=SqlPassword specification as long as you don't need the improved security provided by not trusting the server certificate:
cntemp.Open "Provider=MSOLEDBSQL;Server=dbserver.example.com;Initial Catalog=MyDB;User ID=sa;Password=secret;Trust Server Certificate=True;DataTypeCompatibility=80;"
At first, I'd like to state that all credit goes to #Dan Guzman. It's his answer / comment which provided the solution.
However, I'd like to add some background, based on research I've done since posting my question.
The problem is that Microsoft's documentation obviously is wrong. Please have a look at the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-connection-string-keywords-with-oledb-driver-for-sql-server?view=sql-server-2017#table3_1
It is located in the section SQL Server 2017 -> OLE DB -> Applications -> Using connection string keywords with OLE DB Driver for SQL server, so it should be the right one. It is divided into three sections; in the context of this question, the last table is what we're interested in, because only this one relates to connection strings with ADO.
That last table explicitly shows that Authentication=SqlPawword is valid in ADO / OLE DB connection strings (reformatting mine, no content altered):
Authentication SSPROP_AUTH_MODE Specifies the SQL or Active
Directory authentication used. Valid values are:
(not set): Authentication mode determined by other keywords.
ActiveDirectoryPassword: Active Directory authentication using login ID and password.
ActiveDirectoryIntegrated: Integrated authentication to Active Directory using the currently logged-in user's Windows account
credentials.
NOTE: It's recommended that applications using Integrated Security (or Trusted_Connection) authentication keywords or their corresponding
properties set the value of the Authentication keyword (or its
corresponding property) to ActiveDirectoryIntegrated to enable new
encryption and certificate validation behavior.
SqlPassword: Authentication using login ID and password.
NOTE: It's recommended that applications using SQL Server authentication set the value of the Authentication keyword (or its
corresponding property) to SqlPassword to enable new encryption and
certificate validation behavior.
It also says (again, formatting mine, no content altered):
Trust Server Certificate SSPROP_INIT_TRUST_SERVER_CERTIFICATE
Accepts the strings "true" and "false" as values. The default value
is "false", which means that the server certificate will be validated.
Every reasonable human being will understand this in the sense that Trust Server Certificate=true will disable certificate validation.
But when you look here
https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017
you'll notice that this document is structured like the first one, and that the last table does not mention the Authentication parameter.
However, this document is located in SQL Server 2017 -> Development -> SQL Server Native Client -> Applications -> Using Connection String Keywords. That means that it is not relevant for our case because it relates to SQL server native client (and not OLE DB), but it provides the correct information.
So we have the right document which provides the wrong information and an irrelevant document which provides the right information. Congratulations, Microsoft, you have made me waste a whole day again ...
Furthermore, I have found the following document:
https://learn.microsoft.com/en-us/sql/connect/oledb/features/using-azure-active-directory?view=sql-server-2017#encryption-and-certificate-validation
Reading the title ("Using Azure Active Directory"), it should relate to Azure only. However, I suspect that the following section relates to local SQL server installations as well (formatting mine, no content altered):
Certificate validation
To improve security, the new connection properties/keywords respect
the TrustServerCertificate setting (and its corresponding connection
string keywords/properties) independently of the client encryption
setting. As a result, server certificate is validated by default.
Note
Certificate validation can also be controlled through the Value field
of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI18.0\GeneralFlags\Flag2
registry entry. Valid values are 0 or 1. The OLE DB driver chooses the
most secure option between the registry and the connection
property/keyword settings. That is, the driver will validate the
server certificate as long as at least one of the registry/connection
settings enables server certificate validation.
So it could well be that we also have to change values in the registry to finally disable certificate validation when connecting to SQL server via ADO / OLE DB.
When trying to load a text file using the Azure SQL DW Upload Task in SSIS, I get the following error:
Error: 0x0 at Azure SQL DW Upload Task, Azure SQL DW Upload Task:
Failed to upload to blob storage. Unable to create Azure Blob
container. Endpoint: https://[removed].blob.core.windows.net/,
Container Name: [myContainer]. The remote server returned an error: (403)
Forbidden. The remote server returned an error: (403) Forbidden
Tthe SSIS task is failing.I also tried the BLOB upload task and that fails. Any help is appreciated.
Cause
When a client accesses a storage account using a TLS version that does not meet the minimum TLS version configured for the account ( you have configured the minimum TLS version as TLS1.2), Azure Storage returns error code 400 error (Bad Request) and a message indicating that the TLS version that was used is not permitted for making requests against this storage account.
Resolution
The TLS version used by Azure Feature Pack follows system .NET Framework settings. To use TLS 1.2, add a REG_DWORD value named SchUseStrongCrypto with data 1 under the following two registry keys (depend on .net framework version you are using in visual studio- you can find that from help menu in VS):
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319
More information
To test that the minimum required TLS version for a storage account forbids calls made with an older version, you can configure a client to use an older version of TLS. For more information about configuring a client to use a specific version of TLS, see Configure Transport Layer Security (TLS) for a client application in this link.
When you enforce a minimum TLS version for your storage account (your storage account configuration sets the minimum TLS version to TLS 1.2) , you risk rejecting requests from clients that are sending data with an older version of TLS.
Reference documentation
https://learn.microsoft.com/en-us/sql/integration-services/azure-feature-pack-for-integration-services-ssis?view=sql-server-ver15#use-tls-12
https://learn.microsoft.com/en-us/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal#test-the-minimum-tls-version-from-a-client
For anyone who deosn't want to beat their head against the wall, here was the issue / solution:
I had "PackageProtectionLevel" set to "DoNotSaveSensitive" so I used Package Parameters to configure Password / SecurityToken and then set those as the task values with an expression. SSIS shold have thrown a better error, but at least its solved
I had "PackageProtectionLevel" set to "DoNotSaveSensitive" so I used Package Parameters to configure Password / SecurityToken and then set those as the task values with an expression. SSIS shold have thrown a better error, but at least its solved
Kindly elaborate. I tried changing "PackageProtectionLevel", but no luck.
I get above error while trying to connect oracle 12c. I try using ojdbc6 and ojdbc7 jar files. I found below comment
------------------->
Bug 14575666
In 12.1, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter has been updated to 11. This means that database clients using pre-11g JDBC thin drivers cannot authenticate to 12.1 database servers unless theSQLNET.ALLOWED_LOGON_VERSION parameter is set to the old default of 8.
This will cause a 10.2.0.5 Oracle RAC database creation using DBCA to fail with the ORA-28040: No matching authentication protocol error in 12.1 Oracle ASM and Oracle Grid Infrastructure environments.
Workaround: Set SQLNET.ALLOWED_LOGON_VERSION=8 in the oracle/network/admin/sqlnet.ora file.
<-------------------
I have one dought to implement above workaround as we have shared database.
If I set SQLNET.ALLOWED_LOGON_VERSION=8 in the oracle/network/admin/sqlnet.ora file will it affect other users ?
Will it affect shared applications and its functionality ?
Setting SQLNET.ALLOWED_LOGON_VERSION=8 in sqlnet.ora affects all connections to the server. You're allowing user authentication with older versions of the password verifier and it affects all users. You can't allow it for just one user. But this isn't going to break other applications that can already connect successfully. It will allow older applications (that use old drivers) to connect too. The best solution is to upgrade all clients if possible but this setting is the workaround and it was made available for this exact purpose.
We are trying to connect to Google Cloud SQL from Eclipse using the Database Development perspective. To do so I'm trying to add a new Database Connection, which I was able to do successfully for a local MySQL instance running on my machine.
The motivation for doing this is that we currently run our JUnit tests against the local instance. However, we are switching to Hibernate and want to make sure that all of our configuration files work with Cloud SQL. As a general guide I've been using:
https://developers.google.com/appengine/articles/using_hibernate
We're diverging slightly in that we're using hibernate.cfg.xml instead of persistence.xml, but I don't think this will actually have a bearing on the current issue of simply connecting to the database. From another answer as well as some Google documentation I'm aware that I can't use the com.google.appengine.api.rdbms.AppEngineDriver, because that needs to be run from an AppEngine instance. Instead I'm trying to follow the directions here:
https://developers.google.com/cloud-sql/docs/external
and am using com.mysql.jdbc.Driver.
I have assigned my Cloud SQL instance an ip address and have added my current ip address to the whitelist, as described here:
https://developers.google.com/cloud-sql/docs/access-control#appaccess
My driver is the Connector/J driver I've been using successfully with the local instance, and the url I'm using is:
jdbc:google:rdbms://my-app:my-cloud-sql-instance/myDatabase
which I got based on:
https://developers.google.com/appengine/articles/using_hibernate
After adding the connection and setting the information I click Test Connection, which worked successfully on my local instance. However, this throws the following error:
java.lang.Exception: Connection failed with unspecified error.
at org.eclipse.datatools.connectivity.DriverConnectionBase.internalCreateConnection(DriverConnectionBase.java:110)
at org.eclipse.datatools.connectivity.DriverConnectionBase.open(DriverConnectionBase.java:54)
at org.eclipse.datatools.connectivity.drivers.jdbc.JDBCConnection.open(JDBCConnection.java:73)
at org.eclipse.datatools.enablement.internal.mysql.connection.JDBCMySQLConnectionFactory.createConnection(JDBCMySQLConnectionFactory.java:28)
at org.eclipse.datatools.connectivity.internal.ConnectionFactoryProvider.createConnection(ConnectionFactoryProvider.java:83)
at org.eclipse.datatools.connectivity.internal.ConnectionProfile.createConnection(ConnectionProfile.java:359)
at org.eclipse.datatools.connectivity.ui.PingJob.createTestConnection(PingJob.java:76)
at org.eclipse.datatools.connectivity.ui.PingJob.run(PingJob.java:59)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Obviously this isn't very helpful.
I've tried fiddling with the url, tried a number of users (none of which require passwords, so I'm leaving the password fields blank), and different versions of the driver for different versions of MySQL. Nothing has worked.
There are perhaps more deep-seated issues with doing it this way, such as how I will easily switch between test and deployment versions of my hibernate.cfg.xml, and I don't have good answers. I was just planning on editing them by hand back to the AppEngineDriver, which means I might run into further configuration issues at that point even if the JUnit tests are passing. Nevertheless, I think getting a connection set up to Cloud SQL that will allow JUnit testing will be a step in the right direction. I'd appreciate any input!
You should use jdbc:mysql://<cloudsql-instance-ip>:3306/<database-name> to connect from an external network. The connection string you are using is to connect from Google App Engine.