I have come across what I think is a bug preventing me from loading an X509Certificate2 on Ubuntu or the Debian-based docker image provided by Microsoft. This means that I can't initialise JwtAuthentication in my web API on these platforms, and I'm looking for help:
Are you successfully using JwtAuthentication on Linux?
If so, how are you initialising an X509Certificate for the JwtBearerOptions?
Can you see a problem with what I'm doing, or suggest a work-around or solution?
I have logged the issue with the corefx team and you can see the full discussion here, but below is the main description of the problem:
I have a Web API running in a docker container. The container is built from the provided 1.1.0 package:
FROM microsoft/aspnetcore:1.1.0
and the Web API binaries are copied in. The API runs fine and returns data as expected until I turn on authentication, at which point it needs an X509SecurityKey to set the TokenValidationParameters.IssuerSigningKey value. It throws an exception when it attempts to initialise an X509Certificate2 from a string value:
string certValue = certificate.Value;
byte[] byteCert = Encoding.ASCII.GetBytes(certValue);
return new X509Certificate2(byteCert);
throws an OpenSslCryptographicException:
Unhandled Exception: System.Exception: Failed to extract the Token Signing certificate from the Federation metadata. --->
Interop+Crypto+OpenSslCryptographicException: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
at Internal.Cryptography.Pal.CertificatePal.FromBlob(Byte[] rawData, String password, X509KeyStorageFlags keyStorageFlags)
at System.Security.Cryptography.X509Certificates.X509Certificate..ctor(Byte[] data)
at Mercury.Shared.Rest.Authentication.AdfsFederationMetadata.GetSigningCertificate()
The string value from which the X509Certificate2 is being initialised is:
MIIC4jCCAcqgAwIBAgIQHWt3kGySgJxPtsalC0EoKzANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJBREZTIFNpZ25pbmcgLSBzdHMuYWxsYW5ncmF5LmNvLnphMB4XDTE2MDkwNzA5MDQyM1oXDTE3MDkwNzA5MDQyM1owLTErMCkGA1UEAxMiQURGUyBTaWduaW5nIC0gc3RzLmFsbGFuZ3JheS5jby56YTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANdq9BEuBRPsTdpngeFyXbfH5lBg5WyENQW0qz2FtDw3AvZhiPdFyvTPZIeZDc4vhg+gPuG8pCxhFa6hPqNIwnLSVuyhUi4/CtZrLghF2wVVcyriijvirzdVp2m56nO31NB5HXbSerTmey1gJsgumr+MiaM2CEI9z5ctwAp66jqM9jVv7kzqIwB33irSck+X97jUa9XVa0/0QPBdrSVUR0i4rmfZ9orRdTKC3IA13bD9duk2Kc9V7t8t/woo80Kbbb3ZseYk5N8AI+7RRw9+oSAm8zZQzBYkNkAMeI1mto1faXsm9Aea4HXbyCbvVOx/JGj5Ki7YK/BtzWAyCgRu0TkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAd9rdJ1V9te8njMHiEuvr1DLVUBt2YdpZ8qGFC2rWDKeEW8iARrMfbtrlQovvE1radxoZ2gWR1AaaoEqzmLvF9fEAZ7xjR2P2UlT+ZgntfMn/c+3j7gWnfGNHIjosaYiyF72q4k6bgOx1TV8X08kD2AMBH27utXeeUQTZTd0bUWaWpr76NrDB95k4P6d0t5bkYsguiQjV+2t5/dSvrbTPVbXQmWGyC53IS2OI37AI2bIaeCCDkRHDoxu+L/DtgH8N60k2CLfa+pf0/cxQCR39p4Z+tquVKfYgJIsdZLD6bbrqK9VdpSR2vyUcDLMTGnO0tuDuzBd/xdhJ0GKbnBv3+g==
The same code runs with no problem on Windows, building a certificate from the same string.
Edit: Note that while I initially encountered this problem running a docker image, subsequent testing has shown that it also occurs using Ubuntu 14.04 + .NET Core 1.1
The problem here is that what is being passed to the constructor are the bytes of the base64 representation of the key, and not the bytes of the key itself.
If this code works on Windows then maybe it's a good idea to create an issue in the .net core github referencing this problem.
Thanks for the answer. For those who would like to copy and paste:
var certificateWithoutHeaderAndFooter = certificateString
.Replace("\\n","")
.Replace("-----BEGIN CERTIFICATE-----", "")
.Replace("-----END CERTIFICATE-----", "");
var certificateBytes = Convert.FromBase64String(certificateWithoutHeaderAndFooter);
var certificate = new X509Certificate2(certificateBase64Bytes);
Related
I have a JSF application that uses Mojarra 2.2.9
and is deployed on WebSphere 8.5.5.4 on clustered environement
and javax.faces.STATE_SAVING_METHOD is set to client.
Even though all my application beans are request scoped, sometimes when the user session is valid and the user is doing post request on a page he gets ViewExpiredException. What may be causing this issue and how can I solve it?
Will changing the javax.faces.STATE_SAVING_METHOD to server solve it? If so, what is the impact of doing this on memory?
Also, does this have anything to do with cluster environement and maybe there's some missing configuration on the Websphere that will solve the issue?
This will happen if the client side state is encrypted by one server and decrypted by other server and the servers don't use the same AES key for this. Normally, you should also have seen below warning in server log:
ERROR: MAC did not verify
You need to ensure that you have set jsf/ClientSideSecretKey in web.xml with a fixed AES key, otherwise each server will (re)generate its own AES key during startup/restart (which is used during encrypting view state).
<env-entry>
<env-entry-name>jsf/ClientSideSecretKey</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>[AES key in Base64 format]</env-entry-value>
</env-entry>
You can use this snippet to generate a random AES256 (32bit) key in Base64 format.
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256); // Use 128 for 16bit key.
String key = Base64.getEncoder().encodeToString(keyGen.generateKey().getEncoded());
System.out.println(key); // Prints AES key in Base64 format.
In case you get Java Security: Illegal key size or default parameters? error, install the cryptography extension as instructed in the link, or else generate a random AES128 (16bit) key instead.
After having the key, make absolutely sure you don't publish/opensource your key.
Further you also need to ensure you have added <distributable /> tag to web.xml so JSF will perform more agressive session dirtying and the HTTP sessions (including view scoped beans themselves!) are properly synced across servers.
Another probable cause of ViewExpiredException with client side state saving is that you've set the Mojarra-specific context param com.sun.faces.clientStateTimeout in web.xml which represents the time in seconds before an incoming client side state is considered expired. This is however unlikely the case here as that context param has a rather self-explaining name which you would have spotted by just glancing over web.xml.
See also:
com.sun.faces.ClientStateSavingPassword - recommendations for actual password?
javax.faces.application.ViewExpiredException: View could not be restored
You must have the distributable tag in your web.xml as mentioned by balusc
OS - Windows 10
.net Environment - .net core 2.1
SDK - Microsoft.Azure.Devices.Client - 1.21.0
Microsoft.Azure.Devices.Provisioning.Client - 1.4.0
Microsoft.Azure.Devices.Provisioning.Transport.Amqp - 1.1.9
Microsoft.Azure.Devices.Provisioning.Transport.Http - 1.1.6
Microsoft.Azure.Devices.Provisioning.Transport.Mqtt - 1.1.8
Description of the issue
I'm trying to connect a simulated device (.net core console app) to IOT hub via azure Device Provisioning Service. This is based on x.509 cetificates (root+ intermediate certificate).
I created the enrolment group ok, then uploaded the root certificate and completed verification.
After that generated the device certificate from root certificate and tried to connect to IOT hub using sample code from below link:
https://github.com/Azure-Samples/azure-iot-samples-csharp/tree/master/provisioning/Samples/device/X509Sample
After having all setup when I tried to connect to IOT bub I'm getting below error, tried all protocol - Amqp,Http,Mqtt...
Microsoft.Azure.Devices.Provisioning.Client.ProvisioningTransportException
HResult=0x80131500
Message={"errorCode":401002,"trackingId":"408d5ad7-aa7c-45a1-b19a-e4af41ccf54b","message":"CA certificate not found.","timestampUtc":"2019-08-23T09:17:53.762099Z"}
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
Below is the input to device client along with certificate:
private static string s_idScope = "0ne00074417";
private const string GlobalDeviceEndpoint = "global.azure-devices-provisioning.net";
private static string s_certificateFileName = "simulateddevicecert.pfx";
Is there anything missing in the setup that is causing this error? Also is there any REST API exposed by azure DPS to register device? (instead of using Azure Devices/Client SDK)
As shown here,
please include the intermediate certificate as well in the certificate chain presented by the device.
The REST API docs for registering a device to DPS can be found here.
In my case error 401002 was caused by mismatched deviceId and CN field in certificate which device used to authenticate.
In my case, I used the wrong connection string.
I used the device connection string instead of the service connection string when trying to call a direct invoke method.
I'm posting this here, because this is among the first search results for the 401002 error, and there's no info on this check on the Azure doc websites.
My code is trying to access a template file on the same server as the application.
It all worked fine until we switched on SSL.
Now when connecting to the file I get a SSLHandshakeException: handshake_failure with not much information on the actual cause of the issue.
If I try to access the file through the browser I get a warning page asking if I want to proceed at my own risk.
Is it a problem with the certificate? Can I bypass it?
Edit: The server is JBoss EAP 6.1 with Java 1.7. It's configured to use TLS1.2.
The bit retrieving the template is:
URL url;
URLConnection urlConnection;
try {
url = new URL(templateUrl);
urlConnection = url.openConnection();
urlConnection.setConnectTimeout(connectionTimeout);
urlConnection.setReadTimeout(connectionTimeout);
BufferedReader breader = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
String line;
while ((line = breader.readLine()) != null) {
strHtmlContent.append(line);
}
}
Handshake error is usually not a problem with the certificate, at least not with the validation of the certificate. It can have several other reasons, typically wrong protocol version, no cipher overlap, missing use of SNI... .
Unfortunately it is impossible to say what the problem is in your specific case but you might narrow it down by trying to access the site with different clients (i.e. browser, curl, ...). If not even a browser can access the site it is probably a misconfiguration of the server.
I am using scribe 1.3.0 for OATH authentication. This is on Tomcat 7 under Ubuntu.
I am pretty sure this is some sort of a pilot error but cannot figure out what is wrong exactly...
I create the service and token in the constructor of my client class:
public Client()
{
m_service = new ServiceBuilder()
.provider(Api.class)
.apiKey(CONSUMER_KEY)
.apiSecret(CONSUMER_SECRET)
.debug()
.build();
m_accessToken = new Token(OAUTH_TOKEN, OAUTH_TOKEN_SECRET);
}
Later on when time comes to make a request I use the service in a function:
OAuthRequest request = new OAuthRequest(Verb.GET,
url);
m_service.signRequest(m_accessToken, request);
Since I added the debug() tag to the ServiceBuilder I get the following output:
signing request: URL
setting token to: Token[xxxx , xxxxx]
generating signature...
thats it.. nothing else happens, the code just seems to die there.
I tried to catch Exception from the m_service call but it does not throw exception.
I had tried this code before on a different Windows machine with Jetty and it worked but I dont have access to that machine or OS anymore..
What could I be doing wrong? Is there anything else I can do to get more debug output?
-Wish
Turns out that I needed to include the apache codec jar files in Tomcat.
I did go back to try my app on Jetty again under Windows, that worked without the codec. I am not entirely sure why linux+Tomcat needs apache codec while Jetty+Windows7 does not..
If I had Maven would not have this issue..
I've searched through web for couple hours on this issue, and none of the answers I found didn't really fit into my problem, so here's me, asking my first-ever question in SOF.
So, I'm trying to open a web-browser from a java program using the htmlunit library. The web site I need to connect requires SSL connection, and the certificate is stored in a USB key. Its iKey2023 product.
The system used to work(I did not write it), but one of the certificates in the USB key expired, so it automatically moved on to the next one (there were 4 certificates in total), and it suddenly stopped working.
It is giving me javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated error.
I'm back home now and I forgot the exact name of the method, but I remember the following.
Browser instance is created, using IE8
browser.setWebConnection method was called. This method, according to the API, is an internal API.
Make connection to the website by passing the URL as parameter
It's throwing the exception at step 3.
Some more details. The little details might be incorrect but I'm trying to describe a big picture.
At step 2, the method requites WebConnection object as a parameter, and there is a implementation of that interface. Within this implementation, a keystore is created using sun.security.pkcs11.SunPKCS11(configFileInputStream) (did I spell that correctly?)
It was sth like this.
Provider p = new sun.security.pkcs11.SunPKCS11(configFileInputStream);
Security.addProvider(p);
And create a keystore from this provider.
Using this keystore, within the WebConnection implementation, it creates a SSLSocket.
So, after the certificate has been switched to a new one, it's not picking up the certificate correctly.
Here's what I've tried.
I've tried to use different methods in the htmlunit library, something like setSecurityProvider, and I tried to put the Provider object created in above code snippet. I got class cast exception.
I tried to manually set the system properties(trustStore, trustStorePassword, keyStore, etc). In order to do this, I wanted to export the certificate out of the USB key, but it did not let me export the private key out from it, so I could not really create a valid PKCS12 file out of it (openSSL wanted a private key file along with .pem file for conversion, and I did not have that key file).
They did not work, and I'm so stuck right now.
I have a similar issue. In my case, an admin changed the certificate and I began encountering the same SSLPeerUnverifiedException.
I found that I can set the WebClient to use insecureSSL (prior to calling getPage())and I will no longer get the exception.
webClient.setUseInsecureSSL(true);
This however, doesn't resolve the issue as the server basically doesn't authenticate the client.
Its as if the WebClient is storing something that doesn't work with the new certificate.