When upgrading from OpenSSL 1.1.0 to 3.0.2 an error is being logged when using
SSL_CTX_use_certificate_chain_file.
For example, here's pseudo code that shows a series of successful calls where 1.1.0h succeeds but 3.0.2 fails.
OpenSSL 1.1.0h
method=TLS_method()
ctx=SSL_CTX_new(method)
SSL_CTX_use_certificate_chain_file(ctx,"domain.crt")
---> Returns 1
OpenSSL 3.0.2
fips_libctx=OSSL_LIB_CTX_new()
OSSL_LIB_CTX_load_config(fips_libctx,"C:\Program Files\MyServer\openssl.cnf")
OSSL_PROVIDER_load(NULL,"fips")
method=TLS_method()
ctx=SSL_CTX_new_ex(fips_libctx,NULL,method)
SSL_CTX_use_certificate_chain_file(ctx,"domain.crt")
---> error:03000072:digital envelope routines::decode error
---> error:0A00018F:SSL routines::ee key too small
Question
Any ideas why SSL_CTX_use_certificate_chain_file would fail for 3.0.2 but work fine in 1.1.0?
Got it working with the suggestion from Matt at OpenSSL.
You need to also load the base provider. It is designed to be used in
conjunction with the FIPS provider and does not include any
cryptographic algorithms (only encoders and decoders). See the fips
module guide for a discussion about this:
https://www.openssl.org/docs/man3.0/man7/fips_module.html
The FIPS module does not include any decoders itself - which explains
the "decode error" that you are seeing.
As he noted, I wasn't loading the "base" provider in openssl.cnf, so I added this call
OSSL_PROVIDER_load(NULL,"base")
and modified the openssl.cnf to include the base provider section
which allowed the decoder to work on the cert file
config_diagnostics = 1
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
fips = fips_sect
base = base_sect
[base_sect]
activate = 1
[fips_sect]
activate = 1
install-version = 1
conditional-errors = 1
security-checks = 1
module-mac = 3A:EC:2E:53:3F:92:44:F9:50:13:70:6E:FD:38:37:08:8B:F2:68:56:CC:B4:ED:5F:A1:52:1B:93:15:37:0B:8C
Also, seeing as the value "activate = 1" is set for both fips and base,
I probably don't need any calls to OSSL_PROVIDER_load() since this takes care of it
OSSL_LIB_CTX_load_config(fips_libctx,"C:\Program Files\MyServer\openssl.cnf")
Related
we are currently updating our poky environment to the sumo branch and one of our recipes that build a kernel module does not work anymore. I get the following error when building image rootfs :
- nothing provides kernel-module-ourmodule-4.14.73-linux4sam_6.0-00005-g871f191fa293 needed by ourmodule.ourtarget
This recipe was working with previous version of yocto.
For testing, I made a copy of meta-skeleton/recipes-kernel/hello-mod in our layer, added hello-mod package in our image and built the image. I have the same kind of error:
Collected errors:
* Solver encountered 1 problem(s):
* Problem 1/1:
* - nothing provides kernel-module-hello-4.14.73-linux4sam_6.0-00005-g871f191fa293 needed by hello-mod-0.1-r0.our_target
*
* Solution 1:
* - do not ask to install a package providing hello-mod
Any help is welcome.
Thanks
In My case it was the following issue:
I had the module installed in a non standard kernel-module dir, when removing this it was fixed by adding
RPROVIDES_${PN} += "kernel-module-${PN}"
to the recipe.
Kiwi version 6.0, tcms-api 5.0.
Given that 82 is a valid test run_id and 7 is a valid build_id for the test run's product in the Kiwi instance, run this Python snippet:
from tcms_api import TCMS
kiwi = TCMS()
kiwi.exec.TestRun.update(82, {'build' : 7})
Expect:
The test run's product build is updated from 1 (unspecified) to 7.
Result:
Exception has occurred: xmlrpc.client.Fault
<Fault -32603: "Internal error: 'status'">
There's no other call stack information, so I'm at a loss to further debug. I've tried updating a couple of different fields (manager and status) with the same result. I also get the same result if the value I'm trying to update is unknown/invalid.
Additional information: the equivalent call to TestCaseRun.update() API works. I.e., I can update the build information on a TestCaseRun instance.
#s-manke. This is a genuine bug. I've implemented a hot-fix here: https://github.com/kiwitcms/Kiwi/pull/553
so you can at least continue to use the API.
I am in the process of cutting a new version anyway so this hot-fix will go in. However the API will not process status or stop_date fields at the moment.
I have two AppEngine modules, a default module running Python and "java" module running Java. I'm accessing the Java module from the default module using urlfetch. According to the AppEngine docs (cloud.google.com/appengine/docs/java/appidentity), I can verify in the Java module that the request originates from a module in the same app by checking the X-Appengine-Inbound-Appid header.
However, this header is not being set (in a production deployment). I use urlfetch in the Python module as follows:
hostname = modules.get_hostname(module="java")
hostname = hostname.replace('.', '-dot-', 2)
url = "http://%s/%s" % (hostname, "_ah/api/...")
result = urlfetch.fetch(url=url, follow_redirects=False, method=urlfetch.GET)
Note that I'm using the notation:
<version>-dot-<module>-dot-<app>.appspot.com
rather than the notation:
<version>.<module>.<app>.appspot.com
which for some reason results in a 404 response.
In the Java module I'm running a servlet filter which looks at all the request headers as follows:
Enumeration<String> headerNames = httpRequest.getHeaderNames();
while (headerNames.hasMoreElements()) {
String headerName = headerNames.nextElement();
String headerValue = httpRequest.getHeader(headerName);
mLog.info("Header: " + headerName + " = " + headerValue);
}
AppEngine does set some headers, e.g. X-AppEngine-Country. But the X-Appengine-Inbound-Appid header is not set.
Why am I'm not seeing the documented behaviour? Any suggestions would be much appreciated.
Have a look at what I've been answered on Google groups, which led to an issue opened on the public issue tracker.
As suggested in the answer I received you can follow, for any update, the issue over there.
I've been unable to find any easy way of figuring out the version string for a WAR file deployed with Tomcat 7 versioned naming (ie app##version.war). You can read about it here and what it enables here.
It'd be nice if there was a somewhat more supported approach other than the usual swiss army knife of reflection powered ribcage cracking:
final ServletContextEvent event ...
final ServletContext applicationContextFacade = event.getServletContext();
final Field applicationContextField = applicationContextFacade.getClass().getDeclaredField("context");
applicationContextField.setAccessible(true);
final Object applicationContext = applicationContextField.get(applicationContextFacade);
final Field standardContextField = applicationContext.getClass().getDeclaredField("context");
standardContextField.setAccessible(true);
final Object standardContext = standardContextField.get(applicationContext);
final Method webappVersion = standardContext.getClass().getMethod("getWebappVersion");
System.err.println("WAR version: " + webappVersion.invoke(standardContext));
I think the simplest solution is using the same version (SVN revision + padding as an example) in .war, web.xml and META-INF/MANIFEST.MF properties files, so you could retrieve the version of these files later in your APP or any standard tool that read version from a JAR/WAR
See MANIFEST.MF version-number
Another solution described here uses the path name on the server of the deployed WAR. You'd extract the version number from the string between the "##" and the "/"
runningVersion = StringUtils.substringBefore(
StringUtils.substringAfter(
servletConfig.getServletContext().getRealPath("/"),
"##"),
"/");
Starting from Tomcat versions 9.0.32, 8.5.52 and 7.0.101, the webapp version is exposed as a ServletContext attribute with the name org.apache.catalina.webappVersion.
Link to the closed enhancement request: https://bz.apache.org/bugzilla/show_bug.cgi?id=64189
The easiest way would be for Tomcat to make the version available via a ServletContext attribute (org.apache.catalina.core.StandardContext.webappVersion) or similar. The patch to do that would be trivial. I'd suggest opening an enhancement request in Tomcat's Bugzilla. If you include a patch then it should get applied fairly quickly.
I'm trying to load a dictionary that comes in with Debian Squeeze. Unfortunately radius-client library fails on some included file with:
rc_read_dictionary: unknown Vendor-Id encrypt=1 on line 7 of dictionary /usr/share/freeradius/dictionary.compat
The line is
ATTRIBUTE Password 2 string encrypt=1
Freeradius is installed from the package, so I assume this should work just fine... What could be the problem here?
Late answer, but it still might help others, I got bit by a related issue.
You're getting that error because you're trying to use a dictionary file designed for the FreeRADIUS server. The client library "freeradius-client" is not 100% compatible with that format. Specifically, in your case, it cannot handle the encrypt=1 property of the attribute.
The reason for the complaint about an unknown Vendor-Id is another incompatibility between FreeRADIUS server and the freeradius-client library. FreeRADIUS server expects dictionary files with vendor specific attributes (VSAs) like the following:
VENDOR Cisco 9
BEGIN-VENDOR Cisco
ATTRIBUTE Cisco-AVPair 1 string
ATTRIBUTE Cisco-NAS-Port 2 string
...
END-VENDOR Cisco
The freeradius-client library however can only parse VSAs in the following form:
VENDOR Cisco 9
ATTRIBUTE Cisco-AVPair 1 string vendor=Cisco
ATTRIBUTE Cisco-NAS-Port 2 string vendor=Cisco
The above is true for FreeRADIUS server v2.1.x and freeradius-client v1.1.6.