I am using PyOpenSSL which is the thin wrapper of OpenSSL to add the extension 'subject directory attributes' to a certificate by a Python program. The extension names 'subjectDirAttrs' and 'subjectDirectoryAttributes' have been tried but the error occurs:
"OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'unknown extension name'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]".
As PyOpenSSL is the wrapper of OpenSSL, can anyone make it clear that whether OpenSSL supports the extension 'subject directory attributes' and what is the proper name in programming if OpenSSL supports it?
The other question is the error is reported as follows when I add the extension 'certificate policies' to a certificate by PyOpenSSL.
"OpenSSL.crypto.Error: [('X509 V3 routines', 'DO_EXT_NCONF', 'no config database'), ('X509 V3 routines', 'X509V3_EXT_nconf', 'error in extension')]"
What is the config database? Does it refer to /usr/local/ssl/openssl.cnf? How to use it to add the extension 'certificate policies' to a certificate by PyOpenSSL?
Many thanks!
Does OpenSSL support the extension 'subject directory attributes'?
It kind of depends. OpenSSL can work with a certificate that has them, which means things won't fail with an "unsupported" error if they are present. The problem is, there's nothing available to parse them for user programs. You have to roll your own parsing logic.
Also see How to parse Subject Directory Attributes Extension? on the OpenSSL users mailing list. The thread offers some suggestions for parsing them. Here's from the thread:
"Someone would have to write ASN1 parsing code. There are examples all over the place within OpenSSL; see the various d2i_XXX and i2d_XXX functions. There are macro/define’s available to make the job easier. But, it is not really documented."
"Looks like the type isn't X509_NAME_ENTRY but X509_ATTRIBUTE and the extension
is a SEQUENCE OF Attribute. We don't have the direct equivalent as a specific
type IIRC but it isn't hard to add one just follow what is done for
GENERAL_NAMES which is a SEQUENCE OF GENERAL_NAME... You can either add a custom extension or just parse the structure from the
extentsion contents."
Related
I am trying to get RODBC to work on heroku. I have a rails app that calls an R script from RinRuby, which then queries the production database in order to do some analysis. It all works fine on my local Mac, so I thought the best approach was to use the binary compiled on my Max (psqlodbcw.so) into my repo, and reference it in production as well. Unfortunately, when I try to make the connection in production using this connection string:
> library(RODBC)
> dbhandle <- odbcDriverConnect('driver=./psqlodbcw.so;database=nw_server_production;trusted_connection=true;uid=nw_server')
Warning messages:
1: In odbcDriverConnect("driver=./psqlodbcw.so;database=<db_name>;trusted_connection=true;uid=<user>") :
[RODBC] ERROR: state 01000, code 0, message [unixODBC][Driver Manager]Can't open lib './psqlodbcw.so' : file not found
2: In odbcDriverConnect("driver=./psqlodbcw.so;database=<db_name>;trusted_connection=true;uid=<user>?") :
ODBC connection failed
I have seen this error in a similar post online here, but using SQL server instead of postgres. But the accepted answer on that post doesn't explain why the file isn't found, despite being in the app directory. I did follow the same approach and made my own custom buildpack (available here: https://github.com/NovaWulf/r-rodbc-buildpack). I replaced the .so file with the one I compiled on my mac, and simply deleted the .rll file and the code that copies it, since I don't have that file (and hopefully don't need it for psqlodbc?). When I run that buildpack it runs without error on heroku, but then when I reference the .so file copied from the buildpack, I get the same "file not found" error.
Is this happening because the .so file was compiled on the wrong system architecture? I tried compiling psqlodbc on linux, but I do not get a psqlodbcq.so file when I do that (let alone an .rll file). The closest thing I get is a file called libodbcpsqlS.so, which is a setup file, not a driver file.
Could someone please help me understand the best approach to this problem? Why is heroku not seeing the file that is not there? And what is the best solution? Is there a simple way to just download the correct driver file somewhere?
Any help is much appreciated!
Best,
Paul
I am playing with the CFFI tutorial on Windows 10 and have installed the libcurl-devel package using msys2. I found a file libcurl.dll.a in the directory c:\msys2\usr\lib\ and added this directory to *foreign-library-directories* using:
(pushnew #P"c:/msys64/usr/lib/" *foreign-library-directories*
:test #'equal)
But if I try (use-foreign-library libcurl) I get the following error:
Unable to load foreign library (LIBCURL).
Error opening shared object "libcurl.dll"
What am I missing? I tried to point to libcurl.dll.a directly but the error stays the same:
(define-foreign-library libcurl
(:darwin (:or "libcurl.3.dylib" "libcurl.dylib"))
(:unix (:or "libcurl.so.3" "libcurl.so"))
(t "libcurl.dll.a"))
Here is the complete code as given in the tutorial:
(asdf:load-system :cffi)
;;; Nothing special about the "CFFI-USER" package. We're just
;;; using it as a substitute for your own CL package.
(defpackage :cffi-user
(:use :common-lisp :cffi))
(in-package :cffi-user)
(pushnew #P"c:/msys64/usr/lib/" *foreign-library-directories*
:test #'equal)
(define-foreign-library libcurl
(:darwin (:or "libcurl.3.dylib" "libcurl.dylib"))
(:unix (:or "libcurl.so.3" "libcurl.so"))
(t (:default "libcurl")))
(use-foreign-library libcurl)
EDIT
I am using SBCL 1.4.16 from the portacle package.
EDIT 2
Just for the sake of completeness. If I change define-foreign-library to
(define-foreign-library libcurl
(:darwin (:or "libcurl.3.dylib" "libcurl.dylib"))
(:unix (:or "libcurl.so.3" "libcurl.so"))
(t "libcurl.dll.a"))
the errors changes:
Unable to load foreign library (LIBCURL).
Error opening shared object "c:\\msys64\\usr\\lib\\libcurl.dll.a":
%1 ist keine zulässige Win32-Anwendung.
As far as I understand at least the file is found but seems not to be in the right format. I didn't find any further information about the difference between dynamic (.dll) and static (.dll.a) files with respect to cffi and don't have the resources at the moment to further investigate this.
Instead of using use-foreign-library, try loading load-foreign-library. It is lower level code, but it will allow you to experiment with files and paths.
Also use cygcheck to figure out what libcurl.dll depends on. Then make sure you have the components installed, and that they are in PATH.
Finally, check where libcurl.dll lives in your MSYS2. On my system it is in /c/msys64/mingw64/bin/libcurl-4.dll
I recent research about certificate in windows.
I try two different way to install certificate:
1. Use certutil command to install. ex: certutil -addstore -f "ROOT" rootCA.pem
2. Use Microsoft api to install.
certStore = CertOpenSystemStore(NULL, "ROOT")
CertAddEncodedCertificateToStore(
certStore,
X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
rootCACert,
len(rootCACert),
CERT_STORE_ADD_REPLACE_EXISTING,
NULL
)
After installed, I use certmgr.msc to check it success.
And firefox's security.enterprise_roots.enabled set True.
But I found a strange situation.
Firefox only trust certificate which certutil install.
Can somebody tell me why?
Thanks in advance!
According to the Mozilla Wiki there are differences in Versions:
As of version 49, ... Firefox will inspect the HKLM\SOFTWARE\Microsoft\SystemCertificates registry location (corresponding to the API flag CERT_SYSTEM_STORE_LOCAL_MACHINE)
and
As of version 52, Firefox will also search the registry locations HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates and HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates (corresponding to the API flags CERT_SYSTEM_STORE_LOCAL_MACHINE_GROUP_POLICY and CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, respectively).
So it would be nice to know what version you use.
To answer your question: As the flags of the stores searched are named in the wiki it seems you are using the wrong store in your API solution. Have a look at the function CertOpenStore instead of CertOpenSystemStore. This allows to pass e.g. CERT_SYSTEM_STORE_LOCAL_MACHINE as dwFlags to open the store Mozilla searches.
Say I use Windows 7 with code page 950 (Big5, Traditional Chinese), I want to manipulate some files mixed with unicode name such as 简体中文文件.txt (GB2312, Simplified Chinese) with svn.
If I use chcp 950, when I run:
svn add .\简体中文文件.txt
I get an error:
svn: warning: W155010: 'D:\path\to\work-dir\?体中文文件.txt'
not found
svn: E200009: Could not add all targets because some targets don't exist
svn: E200009: Illegal target for the requested operation
If I use chcp 65001 (UTF-8), I get an even worse error:
svn: warning: W155010: 'D:\path\to\work-dir\?体svn: E200009: C
ould not add all targets because some targets don't exist
svn: E200009: Illegal target for the requested operation
I'd like to try chcp 1200 (UCS-LE) but it says:
Invalid code page
It seems that TortoiseSVN can manipulate those files correctly. However I need to write scripts calling svn to run several automated jobs. Is there any solution available?
Programs like svn that use the MS implementation of the C standard library's file IO functions cannot read command input or file names containing characters outside the current code page. You would have to chcp to a suitable code page for each file separately (eg 936 for Chinese).
In theory code page 65001 could cover every character, but unfortunately the MS C runtime has serious bugs that usually break applications when this code page is in use. Microsoft's ongoing failure to fix this long-standing problem leaves UTF-8 a second-class citizen under Windows.
In the future it looks like http://subversion.tigris.org/issues/show_bug.cgi?id=1537 should fix the problem by using direct Win32 APIs instead of C stdlib to do console writes, though I can't see where the related code change is to confirm whether console input and file access are similarly addressed.
I can't get windows 8 (release preview) to accept either the inf2cat or makecat approach described as solutions to the question at
What changed in the driver signature requirements for Windows 8?
unless I disable validation.
I am not signing these with any certificates at this point, just trying to get past the errors preventing the drivers from installing at all.
Windows 8 gives me a very nondescript error:
"A problem was encountered while attempting to add the driver to the store."
Looking in the event logs, there is nothing of use; only an informational entry from "Windows Error Reporting" indicating a PnPdriverimporterror.
When i use my original files with the cab files that don't match the inf, I get the error everyone else is listing:
The hash for the file is not present in the specified catalog file.
I have one .inf file that i need to generate a .cat for.
Perhaps I am doing something wrong. Ideas??
INF2CAT Approach
c:\win_xp_vista32_64>inf2cat /driver:"." /os:XP_X86,XP_x64,Vista_X86,Vista_x64,7_X86,7_X64,8_X86,8_X64
.......................
Signability test complete.
Errors:
None
Warnings:
22.9.10: usbser.sys in [drivercopyfiles.nt] is missing from [SourceDisksFiles] s
ection in \mchpcdc.inf; ok if file source is provided via LayoutFile in [Version
].
22.9.10: %driverfilename%.sys in [drivercopyfiles.ntamd64] is missing from [Sour
ceDisksFiles] section in \mchpcdc.inf; ok if file source is provided via LayoutF
ile in [Version].
Catalog generation complete.
c:\win_xp_vista32_64\mchpcdc.cat
MAKECAT approach
--- start of catalog.cdf file---
[CatalogHeader]
Name=mchpcdc.cat
ResultDir=.\
[CatalogFiles]
<hash>mchpcdc=.\mchpcdc.inf
---end of .cdf file ---
c:\win_xp_vista32_64>makecat catalog.cdf
These same files, w/ the cat from either approach install just fine in Windows 7.
I think this problem is to do with "windows driver signing enforcement". You can resolve this by disabling this option. Go through with below link:
http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html
I just tested this on Windows 10 and 8 PRO now, to get this right, follow these steps:
1) From your Start menu, locate your DDK's "x64 Checked Build Environment" i.e. the custom DOS build screen. Right-click, run-as administrator...
2) Compile your source with the Build tools etc.
3) Go into your compiled code, and then create your test-certificate (you don't need to purchase one just yet, use your self-signed one created with the line below):
makecert -r -pe -ss PrivateCertStore -n CN=newhex.com(Test) NewhexTest.cer
The above means your certificate is called "newhex.com(Test)" and the generated file is "NewhexTest.cer"
4) Create / Edit your .CDF file which contains items about what your CAT file's contents.
5) Create your CAT file by executing:
makecat -v MyCDF.CDF
This should generate an un-signed CAT file that includes all files specified by your CDF.
6) Sign your CAT file as follows:
Signtool sign /v /s PrivateCertStore /n newhex.com(test) /t http://timestamp.verisign.com/scripts/timestamp.dll MyDriverWhatever.cat
This should result in a CAT file that is signed, but don't just install it, because your Windows can't trust Newhex's cert since it's not in the keystore, to fix this do:
7) Add your certificate to your private Key Store, remember this step MUST be done by an administrators access, otherwise you will get an error about (Keystore not found etc):
certmgr.exe -add NewhexTest.cer -s -r localMachine root
This should add into your keystore, Once done, you can then:
8) Go into your device manager, and add your new driver, you would get a warning but will be accepted and installed without the need to reboot with a forced (Don't check cert type account).
I tried this already and it works on Windows 10 and Windows 8 pro versions.
Kind Regards
Heider Sati
You are supposed to use inf2cat, not makecat, because you have an INF file.
You should work on addressing those warnings from inf2cat by fixing your INF file. Here is my INF file that uses usbser.sys and doesn't cause any warnings: https://gist.github.com/3647208
I was able to fix my INF file thanks to the advice from chinzei in the first post of this thread: http://www.microchip.com/forums/m488342-print.aspx
If you continue to have trouble, please edit your question to include the source of your INF file, or at least a link to the source.
I encounter the same problem and was able to install my driver with a TEST certificate using the instructions provided here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487328.aspx