My application is written using Delphi 2007 and Indy 10. It uses certificates in .p12 files. I set Indy's CertFile, KeyFile and RootCertFile properties and everything works great.
But soon, it will be used for certificates stored on cryptographic cards or tokens.
Can Indy load SSL certificate from a cryptographic card or token?
If not, how can I improve the application to use a certificate stored on a cryptographic card or token?
Related
I'm trying to access a certain API and I have been provided with a smart card which contains the certificate that I'm supposed to use to establish a SSL connection with the said API. I'm trying to do this through a Delphi appliction.
The following is the info of the certificate:
The certificate used to establish a secure connection is stored on a
smart card and it can be accessed from the PKI Applet using PKSC#11
API. The certificate is loaded in the slot / token structure on the
PKI Applet. After the certificate is extracted from the smart card (in
DER format) it can be used as a standard X.509 certificate for TLS/SSL
and HTTPS protocols.
I'm able to extract the certificate (via pkcs11CertificateStorage tool from SecureBlackbox) but I'm hvaing trouble using it for a SSL connection with Delphi.
Here's a simplified version of what I'm doing to attach the certificate to the request (using ipWorks REST component):
var
CertStorage: TsbxCertificateStorage;
ipwREST1: TipwREST;
// ...
CertStorage.Open('pkcs11://user:' + Pin + '#/' + StorageFilename + '?slot=0'+ RO);
ipwREST1.SSLCertEncodedB := CertStorage.Certificates[0].Bytes;
ipwREST1.Get('https://...');
The error that I get from the REST component:
273: Could not acquire security credentials: error 0x8009030E
Which led me to the error explanation by the component developer:
When using a certificate for client authentication, ensure the certificate's private keys are accessible. The certificate in the Windows certificate store must contain the corresponding private keys, and be marked as exportable.
and I'm not sure how to interpret this.
I've tried saving the certificate in a file, using openSSL to convert to PEM and attaching it in other ways but with no success.
I feel like I'm missing something in my approach. Any help would be appreciated, thanks.
I'm creating a coap server with DTLS as security layer that will use digital certificates, x509.
The Coap Server is a data bridge to a cloud server (CA) that uses x509 as authentication.
I also have a device that directly connects to the Cloud server using the same authentication method.
A couple of functions of the device, also needs to communicate with Coap server.
Thus the cloud server is the CA for issuing digital certificates both the device and the Coap data bridge.
I wanted to reuse the certificates (used to communicate to the Cloud Server) in device for connecting to the Coap server. Since the the device is a constraint thing, having multiple certificates are not advisable. Is this possible?
Yes, but there are some pitfalls:
RFC7252 - DTLS - x509
Implementations in Certificate Mode MUST support the mandatory-to-
implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified
in [RFC7251], [RFC5246], and [RFC4492]. Namely, the certificate
includes a SubjectPublicKeyInfo that indicates an algorithm of
id-ecPublicKey with namedCurves secp256r1 [RFC5480]; the public key
format is uncompressed [RFC5480]; the hash algorithm is SHA-256; if
included, the key usage extension indicates digitalSignature.
Certificates MUST be signed with ECDSA using secp256r1, and the
signature MUST use SHA-256.
So, you either use ECDSA (ECC certificates, not RSA), or you need to check, if your server is able to handle it. For Eclipse/Californium the node's certificate must be ECDSA, the other certificates in the path may use other algorithms, if they are supported on your platform.
By the way, I'm not sure, if you really benefit from x509, but that depends on the platform your using on your devices.
X509 certificate and key could be used for several purposes. Examples include,
digital signature
key enciphering purposes
data enciphering purposes
key agreement
so on and so forth
More details could be found here
Now, as per to the description of your problem, you are inquiring whether to use the same certificate/key pairs for both to
Authenticate against the cloud server
Use it for communication ( Encipher/Decipher) purposes with the COAP server
Ofcourse you can use it as long as the (KeyUsage) extension specifies the intended use of the certificate. Refer link above for KeyUsage extensions in X509 certificates
I state that I am not an expert.
I'm trying to create a TCP server / client encrypted. I have implemented SSL, and I created a key selfsigned and its certificate.
I realized, thanks to many post also read on this site that i do not need to use the certificate. I refer in particular to a user's response Remy Lebeau: Delphi Indy - How to get SSL certificates for a SSL-TCP Client/Server link with Indy 10
Now I was wondering if you can, somehow, prevent attacks man in the middle.
Or rather, if I implement the code of the app the signature and fingerprint of the certificate and verify during event OnVerifyPeer is enough?
Good morning,
I wonder how to configure TIdHttp with TIdSSLIOHandlerSocketOpenSSL to use certificates of type USB key, because it is only possible using key file type.
This key is an Alladin, and I wish I could select the key to be used as various certificate if any certificate keys.
thank you in advance
OpenSSL does not natively support using USB keys. Although OpenSSL does have APIs for loading certificate data from memory, Indy does not expose that functionality yet. So at this time, you can only load certificate files from disk. If the USB key has a drive letter assigned to it, and contains certificate files in PEM or ASN.1 format, you can try pointing Indy directly to the USB key's files, otherwise you are basically SOL.
The Application i am working on needs to connect to a webservice over https, The certificate is trusted and valid.
I have used NSURLConnection is previous projects to use soap over http
Can anybody please point the difference between the two above mentioned scenarios,
I also need to understand what exactly happens when connecting over https, is the certificate stored automatically on the device, how does ssl handshake happen.
Any Pointers in this direction will be really helpful.
Regards,
Ishan
I need some clarification. Is the certificate signed by Apple for use with notifications or is it signed by an SSL root certificate authority (like VeriSign)?
Apple signed certificates are only to be used with WebServer to Apple Server communications like the Apple Push Notification Service. They are not intended for iOS device to WebServer.
A SSL certificate signed by a SSL root certificate authority should just work.
I think you are looking for an HTTP over SSL/TLS primer. So, here it goes.
HTTP is an unencrypted channel. The request and response are in a plain text data stream. HTTPS is an encrypted channel. The request and response are in a data stream encrypted using a shared master key. The magic of SSL/TLS is how this encrypted channel is created.
First, the client and server say hello to each other (in a clear channel).
Next, the client downloads the server's public certificate (in a clear channel).
At this point, the client has some work to do. It needs to verify the certificate. It needs to know that it understands the certificate, that the date range is valid, that the certificate is signed by a trusted certificate authority, and that the certificate has not been revoked.
Now, the client knows that it can trust the server.
Next, It sends a few short messages encrypted with the public key of the server (which is in the server's public certificate). These messages can only be decrypted by the server's private key (which only the server knows about). These messages allow the client and the server to negotiate a master key.
Finally, the client and the server begin the normal HTTP request and response using the newly created encrypted channel.
I hope this is what you are looking for. For a more detailed description see: http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
If the certificate was issued by a chain of certificate authorities whose root is trusted by Apple, then there is nothing to do. The iOS device will accept the certificate, as long as it is otherwise valid (ie not expired, not revoked, etc).
If the CA chain's root is not trusted by Apple, you will need to download the root's certificate to the phone. This can be done (I think) via the iPhone Configuration Utility. Enterprise provisioning scenarios undoubtedly support this also.