sertandev: Integration tips: SSL, TLS, Certificates and HTTPS
In this article I will explain you the very basics of SSL/TLS which is widely used in today’s secure connection methods for web browsing, APIs, services and IOT. Although platforms and SDKs often use SSL/TLS behind the scenes without requiring you to implement anything, it is quite essential to have this basic knowledge to keep your integration/communication projects running securely and properly.
SSL protocol released in 1994 by Netscape is designed to solve problems in basic web information security like signing/authorization, message encryption and validation of trust. It is later renamed to TLS for standardization reasons and because of IE-Netscape quarrels. Today, TLS version 1.2 is the most widely used one and version 1.3 is the very-fresh followup version. TLS is a combination of many different optional sub-protocols being different handshake methods, cipher methods, hashing methods. This makes TLS usage vary widely amongs different applications, making it difficult to describe in a fixed workflow that fits all its use cases. We will not get into details of each of these protocols but I will give you some idea over how it is used the very common way.
To understand TLS first we need to take a look at the encryption part. For a secure message transport between client and server, two types of encryption methods are used, symetrical and asymetrical key encryptions. With “keys” we mean simple numbers of different lengths that are used in mathematical equations to encrypt and decrypt the messages.
In symetrical key encrytion, both parties receive the same key and the message is encrypted/decrypted using this key.
Symmetrical key encryption Here it is essential to keep this key secret and prevent it being stolen by a 3rd party, which brings problems if you want to distribute this encryption key for the public web. To solve these problems we have the asymetrical key encryption.
In asymetrical key encryption we have public and private keys which are mathematically related to each other. A message which is encrypted by a public key can only be decrypted using a private key, but not again by the public key itself. So a service can distribute its public key freely to everyone for incoming message encryption and can only decrypt those messages himself.
Asymmetrical key encryption And what if a message is encrypted with the private key instead? Being mathematically related, a message which is encrypted with a private key can be “validated” by its public key without the need to completely decrypt it. So this method also solves the problem of signing as well and used in validation of trust
In secure message transport, digital certificates are the most important component being used for key exchange, signing and validation of trust purposes. It is very important to understand how they work and what different formats they have because “certificates” are the most common objects where things go wrong in integration/communication projects.
A certificate is simply an encrypted/signed bundle of information representing a digital entity. The information contained by a certificate is defined by standards and the most popular one we know is the X509 standard. Certificates used in web are issued by trusted cerficate authorities, who are simply trusted organizations that comply to certain standards.
A certificate can contain following information:
When you request a certificate from a certification authority, you will receive a package containing the certificate file, private key and other optional stuff. The file extension of the certificate will mostly be .DER, .CER, .PEM. .CRT and key file is .KEY. The PEM and DER stands for the encoding format of the certificate file. PEM is an ASCII format encoding using base64 with standard header and footer pointing the start and end of the certificate. DER format is a binary encoded one.
PEM certificate format Other file extensions does not have a correlation to encoding type of the certificate and can be any format. There are actually no certificate file naming standards on which file extension is used for which encoding type.
You may also encounter certificates shipped with an .PFX, .P12 extension. These files are not certificates but certificate containers in PKCS#12 format. A certificate container contains not only the certificate itself, but also its parent certificates and private key in it. This is actually the area where many of the TLS certificate issues happen. You always need to check what is needed for the API or service you are setting up and what your certificate package contains in it. For example many standard .NET libraries require you to have a private key inside the package but does not give you any error if you initialize without it; until you test that connection and the secure connection get rejected..
You can create a PFX container for yourself from standard PEM certificate files using the following openssl command :
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.pem All CA’s digitally sign the certificate they have issued using the private key of theirs. Any party that receive this certificate then can use the public key of CA to validate if the certificate is really issued by him. For this reason many operating systems and browsers ship with hundreds of certificates from well-known certificate authorities built-in, and update those regularly.
You can also create your own certificates. In this case the issuer and the subject of the certificate will be the same and these are called “self signed certificates”. You can use them for testing purposes or within closed systems. They can also be used for HTTPS communication but then you need to import the certificate into every client computer’s trusted certificate auth. store.
To create your own self sign. certificate you can use the following openssl commands:
openssl genrsa -out privkey.key 4096 openssl req -new -x509 -key privkey.key -out cacert.cer days 1095 SSL Handshake (Standard HTTPS, TLS 1.0-1.2)
To be able to establish a secure connection a web server and a client needs to do what is called a SSL/TLS handshake. Every version of SSL/TLS has a different way of accomplish this, here I will describe the most common workflow:
TLS 1.2 with RSA key exchange
Above example is a very basic SSL handshake for securing the traffic in public facing web sites. Web services on the other hand have more secure endpoints and most of the time not accessible to the public (which makes things a little bit more complicated). Many secure web services need to check the authenticity of the client connecting to them as well as client checks the authenticity of the server using server certificate. To be able to achieve this client also uses a certificate (most of the time given by the web service authority itself) and it gets similarly verified on the server side:
Mutual TLS, differences marked in red This method is known as “Mutual SSL/TLS Authentication”, or the “2-way SSL/TLS Authentication”. In this method, server sends an extra certificate request to the client in “server hello” step to ask for a client certificate. Client then responds with its own certificate which will be verified by the server later.
Web services can make use of additional security methods besides the SSL/TLS protocol. Some of them require additional digital certificates or keys/cipher exchange methods, for example the popular OAuth 2.0 certificate authentication, message digest authentications and private message encryption methods. This article is only about the SSL/TLS protocol and I will not get into details of these other security protocols. However I might write about these in the future of this series.
That is it for now, I hope this information will be helpful to run things smoother in your next secure communication project!
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|kurthatlevik: First Aid Kit for Dynamics 365 for Retail; A messy blog post||Blog bot||DAX Blogs||0||10.05.2018 17:11|
|crminthefield: Creating SSL Certificates for CRM Test Environment||Blog bot||Dynamics CRM: Blogs||0||10.12.2013 02:12|
|NAV Team: Dutch Tax BAPI Support Changing to KPN Certificates (2012)||Blog bot||Dynamics CRM: Blogs||0||05.03.2012 22:30|
|daxdilip: How to: Configure Dynamics AX AIF Services to listen for SSL Requests (https)||Blog bot||DAX Blogs||0||23.01.2011 10:12|
|Опции темы||Поиск в этой теме|