Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

Опции темы Поиск в этой теме Опции просмотра
Старый 11.05.2021, 12:11   #1  
Blog bot is offline
Blog bot
24,236 / 809 (75) +++++++
Регистрация: 28.10.2006
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:

  1. Version: Version of the certificate format, like X509.V3
  2. Serial number: globally unique number for a certificate, if a certificate is revoked from global use, this number is used to compare against a list of global revoked certificates table (CRL).
  3. Subject, Name: the name of digital entity the certificate is issued for, in websites this has to be the domain name (with or without wildcards)
  4. Adress,country,email etc.: information of the certificate entity
  5. Issuer: The certificate authority
  6. Valid from/to: The timespan the certificate is valid for
  7. Signature of CA: A very important bit of a digital certificate, this is the hashed version of the certificate encrypted with CA’s own private key. Using this signature one can verify if the certificate is really issued by this CA by using this CA’s public key (more info on that later). Certificate also contains the algorithm info used for this hashing/signing process as well.
  8. Public key: another important purpose of a certificate is publishing the public key of the certificate owner to the user clients.
  9. Thumbprint: A hashed version of all the info on a certificate. Used for validation purposes and easy comparison of two certificates. Algorithm info is also included.
  10. Revocation info: Certificates used in WWW contain regularly updated information from CA’s to show that they are not revoked. This is done to prevent costly browser roundtrips to CRL servers.

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
  1. Client Hello: The client requests an encrypted session from the web server, it send a list of its supported TLS/SSL versions and Cipher suites, and a random key to be used later in symetrical key creation.
  2. Server Hello: Server responds with choosen TLS/Cipher versions from clients list and sends its own certificate containing server’s public key, and a random key to be used later in symetrical key creation.
  3. After the certificate is verified by the client, it creates a new key called “pre-master” key to create a symetrical shared secret on both sides (In the popular “RSA” key exchange method). There has to be a symetrical secret key to be able to encrypt/decrypt the message traffic on both sides to minimize computational costs. Client encrypts this key with the public key of the server, then sends this key to the server.
  4. Client (optionally) verifies the server’s certificate by using the Certification Authority method described before.
  5. Server receives the encrypted pre-master key and decrypts it with its private key. Then it creates the shared secret with this key also using the client-server random keys in equation. Client also creates a shared secret similarly. In the end the shared secret created on both sides should be similar
  6. Client sends a new message to switch to new cipher method and tells it is finished on its own side. This message is encrypted with the new shared secret key.
  7. Server sends the similar confirming the new method and secure communication session begins.
Mutual TLS/SSL handshake in Web Services

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
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Часовой пояс GMT +3, время: 12:32.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.