Differences between internal testers and external testers in test-flight?

Ans : 

Both internal and external testers will install your app from the TestFlight app. Once invited, they will be sent an email asking them to install the TestFlight app. Once they have done so, they'll be able to install your beta app...

Internal Testers: Think of these users as employees who receive instant updates to your app without approval/review

• Must be added manually via iTC
• 25 Max allowed
• Once your app is uploaded it's available immediately for internal testers (before it has been reviewed)
• All internal testers must be added as a user in your iTC "Users and Roles" settings, which gives them certain permissions (review other answers and the docs for this). You wouldn't want to give just anyone permissions here.
• Do not have a 60-day time limit

External Testers

• Will only be able to use your uploaded build for up to 60 days. If you add additional builds, they can update, and the 60 days starts over again.
• Will be able to test your app after
  1. You have submitted it for review
  2. It gets approved in TestFlight review and
  3. You set it to be available for testing. The review process us usually instant for new builds with the same version number. If you add a new version number, the review process can take up to 48hrs as of 10/2016.
• Up to 2000 email addresses can be added. Each email address will allow a user to install the app on multiple devices. The email addresses do not need to match their Apple IDs.
• They receive an invite to install your app once your first build is available for testing. If you add a new user after making a build available for testing, they'll immediately receive an invite. All users will receive notifications to install newer versions of the app if you upload additional builds.
• Will be disallowed from using your app after you have pushed it to the official app store (which promptly ends the beta) or 60 days have passed since you started the beta, whichever comes first. If you end the beta without launching in the app store, and they try to open it, it will crash. Yay, Apple UX! If you do push a version to the app store with the same bundleName, version, and bundleID (build number doesn't matter), then your beta testers will automatically receive the app-store version of the app when it goes live.

What are certificates and provisioning profile for uploading app to app store?

Ans : 

Certificates - This is a cryptographic certificate granted to you by Apple.  It works just like SSL where you get a certificate signed by an authority.  Apple signs the private key that you use to sign different pieces of your application.  Different certificates create different types of trust.  Some allow you to sign and submit your application for the App Store, while others allow your application's web server to send push notifications to users via APNS.  In the latter case, for instance, Apple uses this certificate to trust the web server sending the push notification.  Otherwise, it would be easy for an attacker to spoof a valid push notification and spam users.  The most common certificate you would create signs the key you use to deploy your application to a device or submit it to the App Store.

When you create a certificate through Apple's developer portal, you have to create your key pair and send a "Certificate Signing Request," which at first is likely pretty confusing to developers just trying to see their application run on a device.
If you visit the developer portal, you'll find you can create certificates for Development or Distribution.  These certificates are rooted to different authorities, so that the two worlds are never confused (though all iOS devices trust both in a seemingly equal fashion).
Provisioning Profiles - Probably the most confusing component in the system, a provisioning profile indicates the devices for which an application is correctly signed.  If you visit the developer portal, you'll notice you can create two types (again called Development and Distribution).  Provisioning profiles say "applications with this Identifier signed with this Certificate's private key are okay to run on these devices."  Now that you know a provisioning profile is tied to a certificate, you can see why you have to decide whether to create a Development or Distribution profile.  Development profiles are limited to 100 devices.  Distribution profiles can either be Ad-Hoc or App Store distribution profiles.  I am not sure whether Ad Hoc profiles have device limits.
You might ask, then, why not always use a Distribution profile?  It can deploy to an unlimited number of devices, and is still attached to a certificate owned by the developer.  Another piece of Apple's security puzzle are Entitlements.  In an iOS application's bundle, you'll find Entitlements.plist, which is a list of capabilities that an application wants.  When signing your application using a certificate intended for distribution, Xcode (really the signing utility) will not allow an entitlement with get-task-allow set to YES.  This is because get-task-allow is what allows a debugger to connect to a process, and Apple doesn't want that happening on apps meant for distribution.

Short Ans : 

1. A Certificate authenticates you as an entity. It can represent you as an individual, or your company.
2. The Identifier is a unique ID for your mobile app.
3. A provisioning profile associates your certificate with the App ID. It is the link between #1 and #2 above.

What are the app id and bundle identifier?

Ans : 
Bundle ID : 
A bundle ID or bundle identifier uniquely identifies an application in Apple's ecosystem. This means that no two applications can have the same bundle identifier. To avoid conflicts, Apple encourages developers to use reverse domain name notation for choosing an application's bundle identifier.
i.e com.iosiqa.newapp or com.iosiqa.app.new

App ID : App ID consists of Team ID + Bundle ID. Team ID is provided by apple to one team in developer account.
i.e ABC12345.com.iosiqa.newapp

What is use of APP ID? 
Whenever you want to enable a capability or application service for your application, you enable that capability for the App ID your application is linked to. This used to be tedious, requiring a visit to Apple's developer website. Xcode has evolved quite a bit over the years and it takes care of the details most of the time.