I borned in North Cyprus (http://en.wikipedia.org/wiki/Northern_Cyprus) and during my work life in Istanbul, I needed to declare that I’m working outside Cyprus for 7 years after university to be able to be exempt from military service.

For this, I spent hours to find an approved notary to seal my working declaration given by my company. Because, Cyrus Embassy only approves specific notaries. They have the Notaries signature samples and certification numbers as a catalog and only working declaration paper approved by those notaries were accepted.

This was how I get rid of military service.

Lets come to the point.

Now, If you check my previous eInvoicing (4-ways of doing eInvoicing in Turkey) and SSL related blog (By the Way, What is SSL?), you’ll notice that a large number of Turkish Companies is going to install NetWeaver PI due to our eInvoicing solution. These blog series are triggered by this situation.

Now, it is time to deep dive into this SSL topic one-by-one.

Currently, TRA (Turkish Revenue Administration) provides 2 systems for eInvoicing infrastructure. One is for Testing Customers eInvoicing System Integrations, the otheri s for Productive eInvoicing Systems.

Integration betwwen customers eInvoicing System and TRA Systems is Web Service Integration and communication is taking place only with HTTPS protocol over 443 port.

TRA, allows customers to use a Self-signed Certificate for Test System but for Productive System, they require a Signed Certificate by a Public CA.

Now, our customers and even consultant within our company, project managers are wondering the difference between these 2 types of certificates.

  1. Why SSL Certificates exists and required?
  2. What is Self-signed and what is Signed Certificate?
  3. Is the traffic encrypted even we use Self-signed certificate?

1. Why SSL Certificates exists?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions.

Without SSL


With SSL


There are 2 reasons why we need SSL certificates:

  • Encrpytion: Hiding what is sent from one computer to another.
  • Identification: Making sure the computer you are speaking to is the one you trust.


  • Computers agree on how to encrypt
  • Server sends certificate
  • Your computer says “start encrypting”
  • Server says “start encrypting”
  • All messages are now encrypted


This is all about trust. If you get a signed certificate from verisign you prove to random clients that your certificate is trusted. If you self-sign the certificate people not having your certificate installed on their computer cannot be sure that they aren’t being attacked by an Man-in-the-middle attack.

If your webserver is just used by you, then you do not need a real CA (such as verisign) to sign your certificate. Just install the certificate on the machines that you want to use and you’re good to go.

For identification:

  • Company asks CA for a Certificate
  • CA creates Certificate and signs it
  • Certificate installed in server
  • Browser issued with root Certificates
  • Browser trust correctly signed Certificates

In here, you can thing that the browser here is the Cyprus Empbassy who is asking for a trusted authority approval to identify you. And trusted authorities here are the notaries who was approving my work declaration papers.

2. What is Self-signed and what is Signed Certificate?

It is always been told that SSL certificates are only secure if they are issued and signed by a trusted signing authority, and that we should never use a self-signed certificate except for limited internal use and for testing purposes. We would be crazy to implement a self-signed certificate in a production environment.

Why Pay a Certificate Authority?

A certificate authority tells your customers that this server information has been verified by a trusted source. The most commonly used Certificate Authority is Verisign. Depending upon which CA is used, the domain is verified and a certificate is issued. Verisign and other more trusted CAs will verify the existence of the business in question and the ownership of the domain to provide a bit more security that the site in question is legitimate.

The problem with using a self-signed certificate is that nearly every Web browser checks that an https connection is signed by a recognized CA. If the connection is self-signed, this will be flagged as potentially risky and error messages will pop up encouraging your customers to not trust the site.

When Can You Use a Self-Signed Certificate?

Since they provide the same protection, you can use a self-signed cerificate anywhere you would use a signed certificate. But some places work better than others.

Self-signed certificates are great for testing servers. If you’re creating a website that you need to test over an https connection, you don’t have to pay for a signed certificate for that testing site. You just need to tell your testers that their browser may pop warning messages.

What it comes down to is trust. When you use a self-signed certificate, you are saying to your customers “trust me – I am who I say I am.” When you use a certificate signed by a CA, you are saying, “Trust me – Verisign/GlobalSign/otherCA agrees I am who I say I am.”

3. Is the traffic encrypted even we use Self-signed certificate?

Whether you get your certificate signed by a certificate authority or sign it yourself, there is one thing that is exactly the same on both:

  • Both certificates will generate a site that cannot be read by third-parties. The data sent over an https connection or SSL, will be encrypted regardless of whether the certificate is signed or self-signed.

In other words, both types of certificates will encrypt the data to create a secure website.

So, for test systems TRA accepts your word that “you’re who you say you are”, but for production eInvoicing Systems, TRA requires a CA (Notary) to approve “who you are”.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Andy Silvey

    Hi Huseyin,

    this is a very nice blog and will be very useful to a lot of people.

    Would you please add tags to the blog for the following:



    this way the blog will be visible for the new SCN NetWeaver Architecture Catagory.

    Thank you and kind regards,


  2. José M. Prieto

    Hi Huseyin,

    Let me also add that there is also another reason, in addition to encryption (privacy, confidentiality) and identification (authentication), we used SSL for. This is integrity (data integrity) which is guaranteed by means of message digests attached to the real information is being sent out.


    José M. Prieto

  3. Martin Voros


    I know I am going to be overly pedantic but I think crypto deserves it. The encryption section that describes SSL handshake is overly simplified. Wikipedia has a nice detailed description of SSL handshake. The details are important.

    I agree that both types of certificates provide an option to encrypt all traffic. But people should be careful because going over SSL does NOT guarantee encryption. The client and server agree on cipher suite (combination of public key algorithm, symmetric function and MAC function) that will be used during session. There are some suites that transfer text in plain text.

    Regarding self-signed vs CA certs. We’ve recently seen some incidents when CA was compromised (e.g. Diginotar). The problem with CAs is that there is no mechanism how you can assign just subset of namespace to one CA (e.g. DNS allows this). E.g. Diginotar was a Dutch CA but they could issue a cert for any domain, not just .nl. Hence an attacker who compromised Diginitar could issue a cert for google.com or facebook.com. If you check your browser what root certs are trusted you will see stuff like Honk Kong Post, Visa, Wells Fargo (these are from latest Firefox). The list of CAs is too broad. Do I trust Honk Kong Post? Why big companies like Visa and Wells Fargo have their own CAs? There are some mechanisms how to defend against these rogue certs like certificate pinning. So if you are really paranoid you prefer self-signed certs. You just need to perform out-of-band verification of cert for the first time when you connect and then everything is good. Another question is who does this out-of-band verification. The problem is that this does not scale. If you are providing a service to million users it’s impossible to use self-signed certs. You need to establish your trust through trusting 3rd party CA.


    1. Andy Silvey

      Hi Martin,

      great feedback and great discussion.

      In your professional opinion, for the enterprise companies, I am talking about household name blue chip companies, on the balance between cost and benefit, what would you recommend them to do ?

      My answer, self signed certs for non-production Sandbox, Development and perhaps Quality systems, and always, as a minimum CA signed (eg Verisign) certificates for Production.

      Where would you recommend the large enterprises to become their own CA ?

      What are the costs involved ?

      Best regards,


      1. Hüseyin Bilgen Post author

        Hi Martin & Andy,

        Thank you both for raising up the level of the dicussion. Actually, that was another discussion about CAs. Why we do have to believe them even in recent history many of them breached and caused problems. Browsers have the list of CAs we’ve to trust but is this really safe? Do we have to sit back and relax when we see Green Lock?

        I would like you both to check a similar discussion in http://www.networkworld.com/news/2011/102811-tech-argument-ssl-certificate-authorities-252516.html where they are talking about Convergence Authentication (http://convergence.io/). It is a new way of providing trust just like LIKE’s in Facebook.


        1. Martin Voros

          Hi Huseyin,

          I mentioned cert pinning as one solution to prevent some issues with the current model. But you mentioned probably the most promising solution in this space. I don’t follow Facebook like connection but that does not really matter.


      2. Martin Voros

        Hi Andy,

        it really depends who is going to access your systems. If you have a system that needs to be accessed by external users (e.g. customers) then your only option is to get a cert from trustworthy CA. Nothing else scales. Having self-signed certs for dev and qa systems is usually fine. A relatively small subset of users who are accessing dev and qa system can easily add self-signed certs to their list of trusted certs.

        In case that you are just integrating two systems under your control then self-signed certificates are fine for this case as well. I don’t see any benefit of having a cert issued by external CA. You could even argue that self-signed cert certs are even more secure because you don’t have to trust 3rd party. When you install a new Netweaver system it does not trust any CA (which is actually really good). You have to manually import a cert. So I don’t see any difference between importing self-signed cert and CA cert. A self-signed cert is under your control. You want to switch to longer key, no problem. 10 minutes and you are done.

        But I agree with your rule of thumb – CA cert for production and rest is using self-signed cert.

        Regarding becoming own CA. I guess you mean when a company rolls out own PKI. This is quite common and own internal CA gives you total control over issuing and revoking certs (similar to self-signed certs). I’ve never been part of PKI rollout but I am pretty sure that it’s really hard to do it and it’s quite expensive. Also as with any enterprise grade system it’s going to expensive to maintain. Hence you really need to have a good business case. I don’t think that just SAP systems could create sufficient business case. You probably want to use certs for other use cases such as user authentication when you deploy your own CA.


  4. José M. Prieto


    Great stuff!!

    By the way very interesting article about the Convergence Authentication. Thanks.

    For me this is of course a consequence caused by the hierarchical model of trust SSL is based on. What I mean if we can’t trust anymore on CAs/DNS, they are like the SSL God I would day, and as you guys pointed out there are good reasons to not trust, the whole model collapses. For me this is most representative weakness of SSL/TLS. So I guess eventually the whole model will change some day in the future and of course this convergence system is an alternative. For sure there will be more to come.

    So this leads to my second point on Andy’s question. I believe the paragraph above and all arguments you guys have pointed out until now are strong enough arguments for mid and big companies to implement their our PKI (I would even dare to say for small ones). In fact as long as the model is still the same, this is what I would recommend. I don’t think in terms of cost it will be a stopper either.

    But as Martin’s pointed out this is only valid as long as there is no interaction with world outside the company boundaries. When you need to interact with rest of the world I can see two main alternatives:

    1. If the user community using the system is spread over world and undetermined (e.g. a shopping site) there is no alternative but go for a trusted CA
    2. In B2B scenarios or when the user community is somehow limited and under control you can think in self-signed certificates together with some kind of control over the certificate dissemination or even what Martin’s suggested of certificate pinning similarly how SSH clients work.


    José M. Prieto

    1. Martin Voros

      Hi Jose,

      I don’t know what you mean by “hierarchical model of trust SSL” but I would argue that SSL does not have hierarchical model. It’s a all or nothing model. Any trusted CA by your browser can issue a cert for any domain. This is not hierarchical. DNS works differently. It’s easy to delegate domain control from domain registrar to a customer. You can register a domain and you automatically get control of all sub-domains. You don’t have to go back to registrar if you want to define a new sub-domain. But lalso you can not just become a google.com. When users enter google.com into their browser they won’t ask your DNS server for IP address. That’s the main flaw of CAs. There is no way of delegation. I don’t remember names but it actually happened. Some big customer asked CA that they would like to be a CA for their domains. So CAs issued them a intermediate cert that was signed by their cert. So they could use it to generate certs as they wanted and external users would trust those certs. So now trusting this CA is not only trusting them that they can protect their root certs properly. You also trust this customer that they won’t allow misuse of their intermediate cert.


      1. José M. Prieto

        Hi Martin,

        I meant by “hierarchical model of trust” nowadays both parties involves in a SSL communication must trust on CAs to identify a given certificate as valid and coming for the subject who claims to be. So I see this like a hierarchy of entities: one on top who both SSL parties trust (i.e. the CAs) and the SSL parties themselves. In fact, there might be several levels since for instance intermediate CAs trust as well on root CAs. That’s all. It’s a term I normally used (maybe mistakenly). Sorry for the confusion anyway.

        Other than this, I fully agree with you that having a delegation model similar to DNS but this time on CA/PKI arenas would have been a great feature. Unfortunately this is not the case.


        José M. Prieto


Leave a Reply