I have to find whether Smart Card has a given certificate in it. For that I am first acquiring the HCRYPTPROV (handle to the CSP) using CryptAcquireContext and then using it to Open the system store (OpenSystemStore) and then enumerating the certificates.
It works perfectly on Windows XP. On Windows 7 it gives issue due to stale/old certs stored in store.
Windows stores/copies the certificates in its store from Smart Card. That means if I have two certificates Cert1 and Cert2 on Smart Card and I have used smart card to logon into windows. then Windows stores these certs in its stores, we can see that by going to IE->Internet Options->Contents->Certificates. Then if I remove the Cert2 from the Smart Card, then also Cert2 is shown in Windows Store and this thing is breaking my code.
So I need to enumerate the certs which are available only on the Smart Card not in the Windows store.
Assuming the HCRYPTPROV you acquire is for the smart card, use CryptGetProvParam with the PP_USER_CERTSTORE parameter:
Obtains the user certificate store for the smart card. This certificate store contains all of the user certificates that are stored on the smart card.
e.g.
HCERTSTORE hCertStore = NULL;
DWORD size = sizeof(hCertStore);
CryptGetProvParam(hProv, PP_USER_CERTSTORE, (PBYTE)&hCertStore, &size, 0);
You can then enumerate the smart card's certificates from the HCERTSTORE as with the system store.
The MSDN page states "Windows XP: This parameter is not supported." but it works fine on XP with the latest Service Pack.
The CNG equivalent is NCryptGetProperty with the NCRYPT_USER_CERTSTORE_PROPERTY parameter.
Related
I am trying to prototype a X509 certificates based group enrollment, and not for only one device (as dice_device_enrollment by default would provide), but for several, and, from what I learned, I will need to implement my own custom HSM library. While most of the latter seems straightforward, I have a difficulty with setting deviceID. The document says the following:
custom_hsm_get_common_name
char* custom_hsm_get_common_name(HSM_CLIENT_HANDLE handle);
Retrieves the common name from the x509 certificate.
Passed to the Device Provisioning Service as a registration Id.
My difficulty is - if "registration ID" is deviceID, and an X509 certificate has only one common name, how am I supposed to provision multiple devices in a group? Or, is there any other way that deviceID is set? Currently by analysing the code of hsm_client_riot.c I can't see that.
Just to close this one. Since July 2019 a new version of Azure IoT SDK for Python has been released, which handles device provision better than the old SDK (which I was referring to). The question is obsolete now. Use the new SDK.
I've been writing client certificate code for iOS using many of the resources here: iOS Client Certificates and Mobile Device Management and I've broken out the process to these steps:
Get the Cert via email or AppConfig
Store the Cert (securely)
Extract Identity and Trust from the Cert.
Intercept failed web requests, create NSURLConnection to manually handle auth responses as per Eskimo's advice.
Turn Identity and Trust into the auth response challenge.
My problem is step 2. SecPKCS12Import function appears to automatically add Identity to the keychain as well as return all Identities and Trusts from the certificates, thus eliminating the need for the convenience function often given ExtractIdentityAndTrust().
But on my 2nd run, I will need the Identity and Trust, not just Identity. My current plan is to store the entire cert raw using SecItemAdd, test for duplicates and use it, but I feel like I should be able to just use SecPKCS12Import then later grab it without also using SecItemAdd.
The documentation that is most confusing is SecPKCS12Import, and I would like a clearer understanding of what it does vs secItemAdd, and if secItemCopyMatching() is the same in the end just to grab the certificate. Is Trust not needed or am I just being literal and it's stored with the identity?
The general save, use, store, grab is working, but I'm using NSData and would prefer to store it correctly
I eventually became more familiar with the KeyChain and Identity vs Trust and learned this:
The Trust is a Cert stored in a place that determines who your custom Certificate Authorities are. It only needs to be tested once, which is why it isn't stored.
Storing the Identity is also a certificate, but needed for later. The keychain considers Certificates/Identities to be a Special/Unique thing so it is stored as its own thing, which is why all the keychain code looks different than just securing a password.
Basically, storing the Trust is unnecessary for future reference, but should be checked for good practice. I personally think an expiration might be handy
I am trying to implement signed code for some PS scripts, and I have a question about trusting certificates.
I know the "right" way to address this is for IT to use Group Policy to trust the certificate office wide. But many of my customers just don't really have that option. My thought is to provide instructions on using CertUtil.exe to do the job, but I wanted to be 100% sure that adding to trustedpublisher this way still results in the certificate being validated by the issuing authority at startup or login, so a revoked certificate in trusted publishers would in fact not be trusted, correct?
Also, give that the tool to be run is a management tool, my initial thought is to use the tool to drive CertUtil.exe. Basically the first time you use it it adds its own certificate, so you get some user interaction required on first use only. But the idea of code creating a trust for itself seems potentially sketchy, and would raise a little flag for me if I was on the other side wearing my IT hat. So, from a PS distribution model standpoint, is setting up one's own certificate considered appropriate, or verboten, or something of a gray area?
If I recall correctly revocation is almost immediate, with a possible short time lag due to pre-fetching. you can find more info on how exactly revocation is handled here - https://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx
As far as adding your own cert I don't see an issue with it but if they require code signing for scripts it won't be able to do it's initial launch, personally I'd send the certutil stuff as a separate script (potentially a batch file) and keep the code you are actually sending over all signed.
I have created one Windows desktop application using Visual Studio 2010. At the time of creating setup for this, in the user interface I am able to Add Dialog with textboxes (for storing username, password, email id, and contact number), but now how do I store them, so that I can use these values so that the user can login to the application using this username and password?
I searched, but didn't get anything as I am doing this the first time, so I don't have an in-depth idea of it.
You have two options:
1. Files
You can store your application Login information in a file with any structure that you want like XML or etc.
If you want to store data for more than one person, you must create a logic with your desired structure for reading/writing data in the file for every one.
Then, you can add it in your application setup project for copy in where your application will install and use its values.
2. Windows OS Registry
you can store your application Login information in a subkey of the Windows OS Registry with any structure that you want.
If you want to store data for more than one person in every Windows OS user account, you must create a logic with your desired structure for reading/writing data in the value of a subkey in the Windows OS Registry.
If you want to have different information for every Windows OS user account, it's better you write your data in the HKEY_CURRENT_USER root of the Windows OS Registry. in the other hand, if you want same information for all Windows OS user accounts, it's better you write your data in the HKEY_LOCAL_MACHINE root of the Windows OS Registry.
It's better you add your application subkey in the Software (in the *HKEY_CURRENT_USER* root) or SOFTWARE (in the *HKEY_LOCAL_MACHINE* root) subkey.
Remember that you must encrypt all data for prevent access to them by
malicious persons.
You can encrypt them and then write them as Binary in your file or
the Binary type value of a subkey in the Windows OS Registry.
We have a .net WPF application running as both XBAP and Desktop etc.I haven't signed any assemblies etc.My question is that
Q1.What kind of Digital Certificate do I need to purchase from VeriSign, Inc., or another certificate authority. to sign my application,use it as Authenticode Certificate (in clickonce) ?
Q2.Can I use this Digital Certificate to sign other applications like installers,assemblies,pdf etc?
Q3.Is one Digital Certificate enough for a company or I have to buy other?
Q4.What happens when the Certificate expires? (So is it better to not have it and screw yourself if no one is gonna hack and plant a virus in you app folder or something ???)
A1. You need a code signing certificate. They come in several flavours, and typically can be converted from one to the other, but it's probably easiest to get an Authenticode one rightaway.
A2. You can use the same cert to sign installers and assemblies (and any .EXE, .DLL, .OCX file). I think the same applies to .PDF, but I've never used that.
A3. I'd go for a single cert for your company.
A4. When the cert expires, you cannot use it for signing anymore. However, as long as you use a timestamping service when you sign your code, already signed files remain valid.
A1: You need code signing certificate. You may choose any provider, but do notice that not all of them are recognized by Windows as "trusted". Among trusted and cheaper ones (cheaper then VeriSign) there is Comodo.
A2: Yes.
A3: One is enough.
A4: You will not be able to sign new code. Old code will remain signed if you used timestamp server (you'll get location of one with certificate). If you opt not to use timestamp server, certification will remain valid, but users will get message that it it expired.