I want to send the public key of the private-public key pair (RSA 1024) generated in my applet to the host application/terminal. Now I have done this by sending the modulus and exponent to the terminal. But is it possible to send this public key in a certificate format? if yes then how?
Possible yes, but it would mean that you would have to implement a minimal Certificate Authority (CA) within your smart card.
And if this certificate is not self signed then you need to generate or import the private key of the CA as well. Furthermore, smart cards are often pretty restricted. For instance, to put an effective/expiry date in the smart card you need a clock. If the clock is not available then you need a trusted time source. If you have a trusted time source on a trusted system you might as well create the CA on that trusted system.
I won't get into the issues of memory management, the implementation of an on card ASN.1 library, the issue that the certificate won't fit in a normal APDU etc. etc. That's just the details.
So generally the amount of operations performed on a smart card is relatively limited. Implementation of a full CA is probably not what you want on such a constrained environment. What you can do however is to create a PKCS#10 compatible certificate request on the smart card and send it to a CA. Even that will be quite a bit of work though.
Related
I am working on an embedded device (Arduino) that connects securely to specific domains. To achieve this, certificates (domains), e.g. arduino.cc:443, are uploaded to the device via an updater tool (WiFiNINA certificates updater in Arduino IDE).
I'm wondering whether these certificates will need to be updated in the future? The plan is to ship the devices to customers, so I'm hoping this will not be necessary.
As long as the server side domain/website/api keeps its certificates updated, I assume it will not be necessary to update certificates on the clients?
Thanks.
All certificates have a limited life time and this is true for client certificates too. Depending on the life time of the certificate and the expected life time of the device this means that the certificate needs to be renewed - assuming that normal certificate validation is done. Of course one might decide to use a different certificate validation on the server, like pinning to a specific public key and ignoring any expiration.
Let us say, I used a queue manager QMGR1 in host1 to create a CSR and obtain a CA-verified certificate labeled ibmwebspheremqqmgr1. Can I use load the same certificate (and its root and intermediary chains) in another host host2 for the a queue managed named same (i.e. QMGR1) ? In other words, a certreq needs to be present when we 'receive' a certificate using rumqakm or no? Can we just 'add' a cert (like we do the chains)? If the question is not clear, please ask, i can provide more details. In my case host2 is production. host1 is a QA environment where we test connectivity. Thanks.
Update question from comments 26DEC16
Specific to MQ, I believe I would have to load CSR first on host2 and then receive the CER again, right? I wonder how do I 'load' the CSR without creating it. I see an option to recreate it in runmqakm, never used that before and not sure if that will work.
TL;DR: Yes.
When you create a CSR using IBM GSKit (e.g. runmqakm), the result is a certificate that is unsigned and the CSR file itself. The CSR is cryptographically bound to the unsigned certificate that remains in the .rdb file of the keystore. The signed CSR cannot be received into just any keystore at that point.
When you receive the signed CSR, it is combined with the pending unsigned certificate and moved to the .kbd file of the keystore. At this point it is a valid personal certificate with the label name you specified (ibmwebspheremqqmgr1 in this case) and the DN that you specified.
Once completed you have a usable personal certificate. If you wanted to use it on another QMgr you would need to get that certificate to that other QMgr in one of two ways:
Copy the set of files that comprise the keystore.
Export the personal certificate to a file and then import that file into the other QMgr's keystore.
If you copied the entire keystore and the other QMgr is also named QMGR1 then you can use them immediately. If the other QMgr has a different name, then you'd have to rename the certificate to something other than ibmwebspheremqqmgr1, or in a modern QMgr set the QMgr's CERTLABL attribute to ibmwebspheremqqmgr1. Generally, you want the cert label to reflect the name of the QMgr using it so a QMgr named QMGR2 with a CERTLABL of ibmwebspheremqqmgr1 is not recommended.
If you import the certificate then you can set the label during the import command.
Keep in mind, the label and the Distinguished Name are two completely different and unrelated things. The distinguished Name is the value that the CA verified and signed off over and is cryptographically bound tot he keys in the cert. It is the thing that a remote connection partner decides whether to trust or not.
The label is how the local QMgr or client finds its own certificate. Imagine you had created two personal certificates, the QMgr needs to know which one to send. It finds the correct one by matching the label of the certificate to the expected value of ibmwebspheremq[qmgr name in lower case] or against the QMgr's CERTLABL attribute if it is not blank.
This is why the certificate label can be changed easily with a GSKit command but the Distinguished Name is immutable.
With this in mind, note that external, and many internal, CAs will expect the certificate Common Name of the certificate to contain the fully-qualified hostname where the certificate will be used. HTTPS clients check that the certificate CN matches the hostname when they connect. For an MQ connection, this is not the case. You can put anything in the CN that your CA will sign and use it on a QMgr of any arbitrary name. So your certificate can have CN=QMGR1 and that QMgr can live on mqhost.yourcompany.com and MQ likes it just fine. However, clients using the new MQ REST API will not! This is an important distinction for people hoping to use the new MQ REST API.
Finally, please note that best practice is to generate the certificates where they will be used, protect them using filesystem permissions, keep them in local storage, and never copy or move them from that location. Public/Private key crypto was invented to solve the very difficult problem of securely exchanging private keys. If the personal certs are copied around it defeats the purpose of using them in the first place.
The various commercial PKI packages (i.e. IBM Tivoli Key Lifecycle Manager, Venafi, etc.) all solve this problem using FIPS-certified algorithms that don't store keys or crypto primitives on disk, securely wipe memory space before releasing it, and in general take excruciating care to not leave keys unprotected in transit, disk or memory. If you must copy personal certs around, use a real PKI package designed for that purpose if the company has one. Otherwise, export them to a .p12 with a very long and random password and avoid email, FTP, or other non-secure means of copying the file around.
I am new to TLS/SSL so this might be a very basic question, but I've been searching a lot an could not find an answer.
I am trying to implement a TLS/SSL client. This client will run on an embedded unit with Windows OS on it (XPe or WES7). My implementation uses GnuTLS.
How do I get the list of trusted authorities to my unit so my client can verify the server's certificate? Is it supposed to be a file stored on the client side, that the client is responsible for keeping up to date? Or can my client somehow get this list from the internet each time it is needed and not maintain it locally?
The Certificating Authority (CA) master certificates are stored client side and the client is responsible for keeping them up to date. Keeping them up to date isn't as hard as it sounds, as CA certificates aren't changed that often - most are valid for 5-10 years at least.
Client side storage is necessary because any given internet site your application uses might be compromised.
To get a list, you might start by looking at the CA certificates distributed with a browser or at the cacerts file distributed with Java. Before releasing your code, you'll probably want to check that the certs you use are genuine by checking them against information provided by the CA.
Go to any Windows machine and run "certman.msc" from command-line. Export each CA certificate (Intermediate Certificates, Trusted Authorities) to file (BER, PEM), then import these certificates into your embedded software. Now you can validate email certificates, the same way Windows does (i.e. using various x.509 related RFCs and CRLs)
I have academical project to build communicator with Public Key Infrastructure. For communication between server and clients I'll use SSL/TLS and I need for them certificates. I have to build Certificate Authority with CRL and I can do this with openSSL but this tool is only good for manual administrative not for making certificates automatically in remote CA.
To be clear: Clients must register and login to communicator using certificates but it should be made invisible for them. I've tried running openSSL as process in Java but it's not working properly - my previous problem.
Have you any good advice for making simple PKI?
You can use and extend EJBCA. It takes some getting used to but it has support for some HSM's, and it should not be hard to create a small PKI with it. Open source.
A replacement for simple operations of OpenSSL, would be Bouncy castle. To have better CA support you should also use the EJBCA.
To create certificates automatically in the client (I assume you use a client web browser) is a bit trickier. Some browser can generate private client keys and then get them signed by the CA server.
Generating client side certificates in browser and signing on server
In that case, I would also use the EJBCA to make it manageable.
Recently we created a server with tomcat and we also add SSL support for this little server. For SSL support, we need a certificate which issued by a third issuer like Entrust, Thawte etc.
A colleague said to me that the certificate is binding to a specific machine. That's once we got the issued certificate, then this cert can't be used in another machine.
I doubt this completely because the CSR doesn't contain any info of the machine. Is that true?
Thanks
The certificate isn't necessarily bound to a particular machine. To be able to "use a certificate" on a machine, you need two things: the certificate itself, and its private key. You should have generated the private key along with the CSR (depending on which tools you've used).
Some systems don't allow you to re-extract the private key (e.g. Windows has an option to import a private key in a way you can no longer export it, but as far as I understand, this can be bypassed if you have sufficient access rights on that machine). In cases where you're using a smart card or hardware token, the private key may be generated there in such a way that you can't extract it (in this case, moving the token to the new machine would make sense if necessary).
The other part is the certificate and its name. The host name(s) in the certificate (which is often also found in the CSR, although that's ultimately not necessary), should be the host name(s) of this machine, as seen by the clients trying to connect to it (see RFC 2818 Section 3.1 for detail on host name verification for HTTPS). As such, although the certificate itself isn't tied to a particular machine in terms of hardware, it will be tied to this host name (which allows you to change the hardware for this machine or its IP address for example).