We have embedded linux devices running .NET Core 3.1 that we want to provision with Azure DPS.
We have a special use case that requires us to use X.509 certificates for device authentication and we want to use the same certificates for device provisioning with Azure DPS.
The CSR is generated on a hardware TPM on the device and signed by a company CA, which is registered in DPS and we have an enrollment group set up for this CA.
Now how can we use this device certificate (public .pem on disk, private key on TPM) for device provisioning? We only found examples using either a full certificate on disk (public and private key in .pfx) or using a TPM with EK enrollment (which we don't want to do, because the manufacturing process is already designed for X.509).
In other words: Is there a way to create an instance of the needed X509Certificate2 class with the public .pem file and pointing it to the TPM for the private key?
Related
Need to authenticate a server using certificate, I have used OpenSSL to generate certificate and it was able to authenticate with certificate by enabling client certificate authentication in IIS.
Now when I export the certificate from the device and tried to install it in the other device it was able to authenticate the server, is there any possible way to link or generate a certificate that will only work for the specific machine?
Yes - keep the private key private.
Moving a certificate by itself to another client won't let you authenticate as the owner of that certificate. You would have to move both the certificate and its corresponding private key.
There are generally two ways you can stop the private key being copied:
Use administrative controls to ensure nobody in your organisation copies the keys. This is usually in the form of an agreement between the certificate issuer and the entity named in the certificate, to the effect that "you shall not copy the private key!!". As you can imagine, depending on the scenario, this might not be that enforceable.
If the certificate is certifying a device, generate and store the private key in a hardware device that is a permanent fixture in that client device. A Trusted Platform Module is an example of a device fitted in most modern end-user devices for this purpose.
If the certificate is certifying a person, generate and store the private key in a hardware device that is issued to that person. A smart-card is an example of such a device. You would probably also need administrative controls here to ensure that the user doesn't share their card with others and that they keep any PINs or other authentication data private.
Note that attempting to certify something like the DNS name of the client device as as unique identifier doesn't work, as DNS, MAC addresses etc. can be spoofed.
I am using Bouncy Castle (C#) to generate self-signed X.509 certificates for a WCF web-service.
I have a use case where certificates are created by an installer running in a user account (eg. System Administrator Account). The installer will also create the Windows user account for the service (eg. My Service Account) which will then use those certificates.
I would not like to make the certificate available to all users on the machine/domain, but only to the authorized Service Account (My Service Account).
In such a case it seems neither StoreLocation.CurrentUser nor StoreLocation.LocalMachine will be able to achieve this?
What would be a reasonable way to solve this use case?
The only way you'll be able to access the certificate from any account is to create them in the LocalMachine store; not if you put them in a specific user store.
Notice that certificates don't have ACLs, per-se. Private keys, however, do.
So the most common way to do this is to store the certificate itself on the LocalMachine store, and then secure the private keys with the right ACLs, granting permissions only to those accounts that actually should have access to the private key (which can certainly be a virtual service account such as NT Service\<ServiceName>).
In modern versions of Windows, you should be able to adjust the permissions on the private key directly from the certificate management MMC snap-in, by using the All Tasks -> Manage Private Keys option on the context menu for the certificate.
I just got started programming WCF services and got my first service up and running for a local police department. They will be using this to lookup plates for overnight parking violations. It's running message security and an x509 certificate for encryption.
Is there a way to package the certificate with the installation or some how have the service create it and download it to the client depending on the authentication I am using?
Right now I am going to be manually installing it on each tough book but would like to automate the process more.
Certificate distribution is a standard task for most enterprise IT departments, applications modifying CA roots is somewhat taboo.
If you are talking about pushing the public key of a server certificate to each client, look at Add a trusted root certification authority to a Group Policy object. If you are talking about creating a client certificate for use of mutual TLS authentication, look at Deploy User Certificates.
If instead you are talking about an ephemeral certificate some other certificate which is only accessed by your application from code, you can add it as an Embedded Resource in your assembly and use it via the X509Certificate2(byte[]) constructor.
I would caution you against putting a private key in your application resources, since any user of the application can do whatever they wish with it. PKI is designed such that Private Keys do not need to be shared. Regardless, Jeff Valore shows a method to do so, which I have reproduced below:
var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("MyCert.cer");
var bytes = new byte[stream.Length];
stream.Read(bytes, 0, bytes.Length);
var cert = new X509Certificate2(bytes, "certPassword");
I developed a secure SMS-exchange application that uses RSA (1024-bit) for session key exchange and Twofish (128bit) for SMS encryption. I used Bouncy Castle API. At this point, I need the application to be able to verify (other) users’ public key. I want this done by verification of users’ X. 509 digital certificate as in regular PKI. How do I go about generating an X.509 digital certificate that can be used on mobile phones (on the j2me application)?
I am developing an html application where an user has to first login using his digital certificate. After login he has to perform encryption and decryption of data using his digital certificate.
Now in case when the certificate is available in the form of .pfx file then we can just install it and the certificate appears in the container and we can use it during login and during encryption and decryption.
This works fine in case if we have .pfx for our digital certificate.
But now i want to enhance it for etoken's(security token). I dont know much about etoken's. The problem is that how can i use the digital certificate stored in it while login?
Also how should i use the private key stored in it while decryption?
Can anyone please tell me about any tutorials (if any) which will explain the usage of etoken and the CryptoAPI's.
As I mentioned in the answer to your previous question, Windows CSPs map the certificate from hardware to Windows certificate storage, so this is transparent to you. If you can access the certificate via Windows certificate storage API, then you don't need to care where the certificate is actually located.
Note that you can't transfer a private key to the server, i.e. you would have to use a client-side module (either ActiveX or Java applet) that will perform operations locally. This is not specific to certificates on hardware, but also to certificates which have non-exportable private keys.