Some other Frequently Asked Questions which not directly related with order procedure are listed in the category Other FAQs,such like customer side questions,product related questions,packing related questions,license related questions,presales related questions,online product display related questions,website related questions,etc.They are frequently asked and the Other FAQs category may help you know answers easily!
More other frequently asked questions in different categories are in updating and adding.
- WebSiteRelated-FAQs 01.Website Contents,Exploring Safety and Security?
We know all our clients care about internet security and safety.The safety issue of exploring and EDI activity are protected both from content side,server side,and also protected by network protocals.
The official website https://www.mdidea.com,the official mirror website https://www.mdidea.net,and its content are tested regularly by our webmasters to make sure safety for visitors and clients!
For exceptions,some scripts(such as Jquery and Plugins etc) are defined as safe scripts for updated web applications standard.Other cases,if you find one,pls report with description in details and related links to us,we will make it checked by site safety professionals.The official herb site provide useful content and knowledge of herbs related and products our factory manufactures,they are useful to all human being folks,including those skilled hackers.
The security and safety of the official website contents also checked by other third party professional testing agencies,thus we and those third party professional testing agency both sure about browsing safety conditions for vistors and clients,the web pages and client service software Do Not contain harmful scripts,Not open pop up windows,and Not permit other scripts which bad to client side exploring computers,Protects you away from those risks(for examples,Computer Threats,Identity Threats,Annoyance,Malware incidents,Out-of-date software,Scams,Rogue web stores,Dangerous links,hacker implanted Parasites,security vulnerabilities,phishing websites,etc).Some testing result from relevant third party testing agency shared as below:
- Test via Norton Safe Web:
Norton Safe Web Test: The third party Norton Safe Web(Symantec Security Check) protects you from Computer Threats,Identity Threats,Annoyance factors.
The Norton Safe Web tested mdidea.com and reported "Norton Safe Web found no issues with this site.Computer Threats:0;Identity Threats:0;Annoyance factors:0;Total threats on this site:0",report available at:Norton Safe Web Report
- Test via Google Safebrowsing:
Google Safebrowsing Test: The third party Google Safe Browsing Diagnostic is easy for you to check if a site is in Google’s suspicious list with malware.
The Google Safebrowsing tested mdidea.com and reported "Not dangerous:Safe Browsing has not recently seen malicious content on www.mdidea.com.",report available at:Google Safebrowsing Report
- Test via Sucuri Security Scanner:
Sucuri Security Scanner Test: The third party Sucuri Security Scanner will scan the website for known malware,blacklisting status,website errors,and out-of-date software.
The Sucuri Security Scanner tested mdidea.com and reported "Status:No Malware Detected by External Scan.Web Trust:Not Currently Blacklisted(10 Blacklists Checked)",report available at:Sucuri Security Scanner Report
- Test via WOT:
WOT Test: The third party WOT(Web of Trust) will show you the website reputations which are rated by its community users,and the color of the result page will be changed according to different rates,but there may be no results for some new websites.WOT Website Checker will "Ensure your internet safety.WOT secures you against scams, malware, rogue web stores and dangerous links"
The WOT Website Checker tested mdidea.com and reported "Good site",report available at:WOT Report
- Test via AVGThreatLabs:
AVGThreatLabs Test: The third party AVG Internet Security protects you from virus & spyware ,also prevents online data theft and scams,stops unsecure links and files,and includes new privacy features to keep your data private.
The AVGThreatLabs tested "Is mdidea.com safe from viruses?" and reported "No active malware was reported recently by users anywhere on this website.",report available at:AVGThreatLabs Report
- Test via Unmask Parasites:
Unmask Parasites Test: The third party Unmask Parasites is based upon Google Safe Browsing Diagnostic,and will show you if a webpage is clean or not,the result report will show you all the links on the site.The official site of Unmask Parasites noted:"Hackers exploit security vulnerabilities in popular web software such as blogs,forums,CMS,image galleries and wikis to insert hidden illicit content into web pages of innocent third-party web sites.Thousands of website owners are unaware that their sites are hacked and infected with parasites."The Unmask Parasites will find if any parasites on the site or not.
The Unmask Parasites tested mdidea.com and reported "Status:clean",report available at:Unmask Parasites Report
- Test via SiteSafetyCheck:
SiteSafetyCheck Test: The third party SiteSafetyCheck is a free service that analyzes a website and calculation safety issues based on Google Safebrowsing,AVG ThreatLabs,WOT Rating,McAffee SiteAdvisor.Site Safety Check combines 4 major services in one.When you see 100% rating for website, you know you can trust it!
The SiteSafetyCheck tested mdidea.com and reported "According to SiteSafetyCheck www.mdidea.com is 100% safe.",report available at:SiteSafetyCheck Report,the SiteSafetyCheck also provide a badge to show the timely status!
- Test via VerifyMySite:
VerifyMySite Test: The third party VerifyMySite is a free service similar as SiteSafetyCheck,it analyzes a website and calculation safety issues based on on information from major players in internet safety such as Google Safe Browsing,AVG ThreatLabs,McAffee SiteAdvisor and Safe Browsing Tool(Web of Trust).It introduction noted "This means that we have safety information for most of the sites on the web,even if one of the providers doesn't.Also some safety providers miss security threats.We show information from all of them,so you won't miss anything."
The VerifyMySite tested mdidea.com and reported "Website www.mdidea.com is Safe according to Google Safebrowsing, Safe according to AVG ThreatLabs, Good according to WOT Rating, Safe according to McAffee SiteAdvisor. VerifyMySite consider this website as Extremly Safe. We consider www.mdidea.com suitable for children.",report available at:VerifyMySite Report,the VerifyMySite also provide a badge to show the timely status!
- Test via Privacy PC:
Privacy PC Test: The third party Privacy PC are a team of enthusiasts with profound understanding of online privacy,malware protection,security vulnerabilities,hacking countermeasures and more areas related to the global threatscape.Its free scanner provide free website safety scanning.
The Privacy PC tested mdidea.com and reported "Currently Safe.",report available at:Privacy PC Report
- Test via Webroot BrightCloud:
Webroot BrightCloud Test: The third party BrightCloud is developed by Webroot(Smarter Cybersecurity) for "Threat Intelligence",Webroot declared "delivers next-generation endpoint security and threat intelligence services to protect businesses and individuals around the globe. Our smarter approach harnesses the power of cloud-based collective threat intelligence derived from millions of real-world devices to stop threats in real time and help secure the connected world."
The BrightCloud tested mdidea.com and reported a Real Time Intelligence Analysis,report available at:Webroot BrightCloud Threat Intelligence Report
- Test via URL Void:
URL Void Test: The third party URL Void is a free service that analyzes a website through multiple blacklist engines and online reputation tools to facilitate the detection of fraudulent and malicious websites. This service helps you identify websites involved in malware incidents, fraudulent activities and phishing websites.
The URL Void tested mdidea.com and reported "No active threats were reported by the scanning engines.",report available at:URL Void Report
- WebSiteRelated-FAQs 02.Web Server and Data Security?
To guarantee and provide a high level availability for herbal friends,the official websitehttps://www.mdidea.com is served by a trustworthy global top level Apache Server provider,which guarantee an industrial standard SLA(Service-Level Agreement) 99.99% Network Uptime Guarantee based on annual statistics,the world class technology of this Apache Server with Linux Operating System used Dual Quad Processor Performance Servers,UPS Power Backup,Diesel Generator Backup Power,24/7 Network Monitoring,Multiple 10 Gigabit Ethernet Connections,etc.Site data and client submit data are stored at the Top Level Safety Guaranteed Datacenter of NYC,USA,North America,it is very safe.
Why sometimes can not visit the official website https://www.mdidea.com?The most common reasons of the down time,we are noticed by host company may including following conditions:(1).Connection failed for server over load for over visiting count;(2).DNS problems;(3).Hardware of the host supplier happened some minor problems and in fixing,or in upgrading;(5).Connection problems of your local ISP;(4).Other unspecific connection reasons or changes from hosting side;Any down line case will be fixed asap to reload in No more than 24 hours.
When this occasional donwtime cases happened,suggest visitors explore products via official website at https://www.mdidea.net.
For another high level availability instead,the official websitehttps://www.mdidea.net is served on an Apache Server from a trustworthy Global Top Level Server Provider too,it also support Gzip and other server and browser side accelerating technology,which makes it responses the same fast as the official website https://www.mdidea.com,the hosting side guarantee an industrial standard SLA(Service-Level Agreement) 99.95%~99.99% Network Uptime Guarantee based on annual statistics,the world class technology of this Apache Server with Linux Operating System used latest generation Performance Servers,UPS Power Backup,24/7 Network Monitoring,Multiple 10 Gigabit Ethernet Connections,etc.Site data and client submit data are stored at a Top Level Safety Guaranteed Datacenter of Amsterdam,Netherlands,Europe,also high performance.
- DNS Propagation for Official Website:www.mdidea.com
The DNS,or Domain Name System(or Service or Server) is a look-up table that resolves internet web addresses like Google.com to their respective IP address,i.e.184.108.40.206–the backbone on which computers are able to connect and communicate.
The official website https://www.mdidea.com served by a cluster of DNS servers from a global famous IT agency at USA,which provide secure,globally available DNS service,built for superior resiliency,it guarantee a very high level 100 percent SLA for DNS Resolution;With service from fully redundant,globally distributed Anycast locations worldwide,it provide Fast Response Time;With combination of a highly available infrastructure and security features(such as DNSSEC),it gurantee Proven Availability and Security,make it more difficult for cybercriminals to perpetrate attacks,minimizing interruptions to customers trying to navigate to website;Some DNS performance global wide test result shared,both in IP scope from multiple name servers located in different parts of the world,and a Map scope accordingly,from the test result,the service is stable enough to all major continents.
- DNS Propagation for Official Website:www.mdidea.net
The official website https://www.mdidea.net served by a cluster of DNS servers from a global famous IT agency at USA,which provide secure,globally available DNS service,built for superior resiliency,it guarantee a very high level 100 percent SLA for DNS Resolution;It also served by fully redundant,globally distributed Anycast locations worldwide to guarantee Fast Response Time,gurantee Proven Availability and Security,minimizing interruptions to customers trying to navigate to website;
Some DNS performance global wide test result shared,both in IP scope from multiple name servers located in different parts of the world,and a Map scope accordingly,from the test result,the service is stable enough to all major continents.
- WebSiteRelated-FAQs 03.Network Transmission Protocols Security?
The Secure Sockets Layer,or SSL in abbreviation,is an industry standard and used by websites in protection information of customers.In Brief,SSL(Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser.This technology ensures that all data passed between the web server and browsers remain private and integral.The SSL(Secure Sockets Layer) is one industry standard of Network Transmission Protocols and used by websites in protection information of customers.
The Secure Sockets Layer(SSL) provides security technology for encrypted links between a browser and a web server.This encrypted connection allows data to be sent over the public network of the internet while remaining private and integral between the browser and the web server.Basically,SSL is an industry standard of Network Transmission Protocols for these secure digital certificate connections.When the protocal works,First,the customer's browser will connect to the secure site and request the site's SSL Certificate.Then,the customer's browser checks to ensure the SSL Certificate has not expired and that it was issued by a trusted Certification Authority.Lastly,the browser ensures the SSL Certificate is being used by the website to which it was issued.If the digital certificate fails any one of those checks will cause the browser to throw an error message.
With the secure HTTPs connection,a Green Lock will appear at the browser address bar,which means this page is secure(valid HTTPS).It show clear information of the "Valid Certificate",which means "the connection to this site is using a valid,trusted server certificate",and guarantee the "Secure Resources",which means "All resources on this page are served securely.",it is easy for a visitor to recognize the authenticated official website,and bring you more safety to avoid harmful scripts,phishing sites,data interception,dns hijacking,and some other malware threats.
The encryption process gives consumers a safer way of paying or making financial transactions.Customers of the 21st century expect a secure connection between a business’s server and their private computers,SSL Certificates mean that the only person reading a customer’s private information is the legitimate business owner or employees of the business.
- Brief Introduction of SSL Evolution and TLS:
SSL and TLS are both cryptographic protocols that provide authentication and data encryption between servers, machines and applications operating over a network(e.g. a client connecting to a web server). SSL is the predecessor to TLS.Over the years,new versions of the protocols have been released to address vulnerabilities and support stronger, more secure cipher suites and algorithms.
SSL was originally developed by Netscape and first came onto the scene way back in 1995 with SSL 2.0(1.0 was never released to the public). Version 2.0 was quickly replaced by SSL 3.0 in 1996 after a number of vulnerabilities were found(Note:Versions 2.0 and 3.0 are sometimes written as SSLv2 and SSLv3.).
TLS was introduced in 1999 as a new version of SSL and was based on SSL 3.0.TLS is currently at v. 1.2, with TLS v. 1.3 currently in draft.
So what’s the difference?
Secure Sockets Layer (SSL) is a cryptographic protocol that enables secure communications over the Internet. SSL was originally developed by Netscape and released as SSL 2.0 in 1995. A much improved SSL 3.0 was released in 1996. Current browsers do not support SSL 2.0.
Transport Layer Security (TLS) is the successor to SSL. TLS 1.0 was defined in RFC 2246 in January 1999. The differences between TLS 1.0 and SSL 3.0 were significant enough that they did not interoperate. TLS 1.0 did allow the ability to downgrade the connection to SSL 3.0. TLS 1.1 (RFC 4346, April 2006) and TLS 1.2 (RFC 5246, August 2008) are the later editions in the TLS family. Current browsers support TLS 1.0 by default and may optionally support TLS 1.1 and 1.2.
Hypertext Transfer Protocol Secure (HTTPS), or “HTTP Secure,” is an application-specific implementation that is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS. HTTPS is used to provide encrypted communication with and secure identification of a Web server.
In addition to HTTPS, SSL/TLS can be used to secure other application-specific protocols such as FTP, SMTP, NNTP and XMPP.
- TLS/SSL Protocol,Layering and HTTPS:Establishing a Secure Connection
The major use of SSL (X.509) certificates is in conjunction with the TLS/SSL protocol.Secure Sockets Layer(SSL) is a Netscape protocol originally created in 1992 to exchange information securely between a web server and a browser where the underlying network was insecure. It went through various iterations and is now at version 3(dating from 1995) and used in a variety of client<->server applications. Since the demise of Netscape the SSL specifications will not be updated further. It is thus a dead standard, (dead as in a dead parrot) and indeed RFC 7568 has finally deprecated SSL v3. It is now officially a dead parrot and must not be used henceforth by order of the great and good (and, in this case, the eminently sensible). The IETF standardized Transport Layer Security (TLS) Version 1, a minor variation of SSL, in RFC 2246, Version 1.1 in RFC 4346 and Version 1.2 in RFC 5246. In addition, a number of extensions are defined in RFC 3546 when TLS is used in bandwidth constrained systems such as wireless networks, RFC6066 defines a number of TLS extensions carried in an extended client hello format (introduced with TLS 1.2), RFC6961 defines a method for reducing traffic when a client requests the server to supply certificate status information. And RFC 7935 now defines what happens to TLS (and DTLS) when used in the IoT (Internet of Things or Thingies as we, in our iconoclastic way, prefer).
When a secure connection is initially established it will, depending on the implementation, negotiate support of the particular protocol from the set SSLv3, TLSv1, TLSv1.1 or TLSv1.2. Such is the pervasive power of the name SSL that in most cases what is called SSL is most likely using TLS - for instance OpenSSL supports both SSL (v3) and TLS (TLSv1, TLSv1.1 and TLSv1.2) protocols. While there are detail differences between SSL and TLS the following descriptions apply to both protocols.Note:SSLv2 was banned by RFC 6176 which contains a dire list of its shortcomings.SSLv3 has now joined its older brother in being banished by RFC 7568.All references to SSL below are retained for reasons of common usage(the term is still more frequently used than TLS) but should be simultaneously translated by the reader into TLS.
TLS/SSL runs on top of TCP but below the end user protocol that it secures such as HTTP or IMAP as shown in the Figure(TLS/SSL Layering).
TLS/SSL does not have a well-known port number-instead when used with a higher layer protocol, such as HTTP, that protocol designates a secure variant, HTTPS in the case of HTTP, which does have a well-known (or default) port number. The designation HTTPS simply indicates that normal HTTP is being run on top of an TLS/SSL connection,which runs over TCP.In the case of HTTPS the well-known port number is 443,in the case of IMAPS-port 993,POP3S-port 995 etc.
The next level of description requires some familiarity with the terms MAC(Message Authentication Code),Secure hashes,symmetric and asymmetric cryptographic algorithms.For those not comfortable with these terms they are covered in in this Encryption survival guide. You may want to lie down for a while in a darkened room after reading this stuff.
Establishing a Secure Connection:
When a secure connection is established using TLS/SSL, for example using HTTPS(default port 443),an exchange of messages occur between the client - which always initiates the connection - and a server. The first set of messages are called the Handshake Protocol after which both client and server enter the Record(or Data) Protocol.The exchange of messages during the Handshake Protocol achieves the following objectives:
Establishes the protocol variant to be used from the supported set (depending on the implementation) of SSLv3,TLSv1,TLSv1.1,TLSv1.2 - the latest possible variant will always be used,thus TLSv1 would always be used in preference to SSLv3 assuming both client and server support both. The client offers a list-the server makes the choice from the offered list.
Sends authentication data.The server sends authentication information most normally in the form of(wrapped in) an X.509(SSL) certificate but other methods are supported by the protocol.
Establishes a session ID so that the session can be restarted if required.
Negotiates a Cipher Suite consisting of a key-exchange algorithm together with a bulk-data encryption algorithm type and a MAC type used in the subsequent data session (Record Protocol). The key-exchange algorithm typically uses an asymmetric (public-private key) algorithm such as RSA, DSA or ECC (Elliptic Curve Cipher - see RFC5289). Asymmetric algorithms are very expensive in resources (CPU) and therefore symmetric ciphers are used for subsequent bulk-data encryption (using the Record Protocol). The key-exchange algorithm is used to transfer information from which session key(s) can be independently computed for the symmetric (bulk-data) cipher. The MAC protects the integrity of the transmitted/received data during the Record Protocol.
This a simplified overview and additional data may be exchanged, for instance, the client can be requested to send an authenticating X.509(SSL) certificate in a process called mutual authentication,but the above describes the most common case and is illustrated in Figure below:
- Certificate Chaining and Certificate Usage:
Certificates may be chained, that is, they may be signed by one or more intermediate Authorities in a hierarchical manner - or a certificate may simply be signed directly by a CA. The concept of a Registration Authority (RA) as an intermediate signing authority is introduced in the RFCs mentioned above. A Registration Authority (RA), sometimes also referred to as a subordinate CA in the EV standards, appears to describe an organization from which the X.509 certificate is actually purchased, for example, a licensed agent, who signs the certificate with the CA (the final signing authority) providing the ultimate or root authority. Somewhat similar in structure to DNS Registry Operators and Registrars for those familiar with the DNS organization. RFC 4158 contains a useful but indigestible and brain numbing discussion about how certificate chains can be reliably constructed using subject and issuer pairs augmented by, among others, SubjectKeyIdentifier and AuthorityKeyIdentifier.
The topmost certificate of the signing hierarchy is known as a root certificate, or sometimes a CA certificate or even a root CA certificate. Root certificates are obtained by a trusted out-of-band process (in the case of browsers they are distributed with the browser software and updated periodically) and when used to validate a certificate chain are generically referred to as trust anchors. When a end-entity certificate (or certificate bundle) is obtained from a server during an TLS/SSL handshake it must be verified by the receiving software all the way to the root or CA certificate including, if appropriate, any intermediate certificates (again these are typically distributed with browser software). A root or CA certificate is recognized if the issuer and subject fields are the same, if the KeyUsage field has keyCertSign set and/or the BasicConstraints field has the cA attribute set TRUE. The process of building the certificate chain is described by RFC 4158 and chain validation by RFC 5280.The chaining process is shown in Figure below:
Certificate Usage:The issuer of a certificate is identified using a Distinguished Name (DN) format which was originally designed to represent a location within a DAP or LDAP DIT (Data Information Tree). The DN should not be confused with a network address or URL/URI. The DN will typically have a format such as CN=Type of Certificate, OU=Certificate Division, O=Certificate Company name,C=Country (CN=, OU=, O=, C= format) but may use simply an OU=, O=, C= format or even a CN=, O=, C= format and to make matters yet more complicated it could use CN=, OU=, DC=, DC= format. It can vary - a lot. A DN consists of a number of comma separated RDNs (Relative Distinguished Names), thus CN= or C= are RDNs in a DN. An X.509 certificate does not contain a URI to obtain any chained certificates via a network interface - but it may contain (in other fields) a URI to obtain CRLs. Applications that use certificates - such as a browser or client email software - must have previously obtained the root certificate, and if the certificate is chained - all intermediate certificates, by some out of band or off-line process. Most common CA root certificates are distributed with browsers (and made available to their associated client email software). Handling certificates using common browsers.
Note: The root certificates distributed with common browser (and email client) software are added according to criteria defined by the browser supplier and vary from "pay us lots of cash" through to full proof of a CA audit and other requirements.
When an application accesses an TLS/SSL based service the server certificate (or a certificate bundle) is obtained during the initial TLS/SSL Handshake dialog. The application, such as a browser, will extract the CN of the subject DN field (and/or the subjectAltName - see RFC 6125) to verify the entity (say a web server address, for instance, www.example.com). It then uses the issuer field DN of the server's X.509 certificate to find the appropriate root certificate from its local store (and generate an exception - normally involving a highly confusing, and potentially dangerous, user dialog - if one is not found). If a valid root certificate is found this authenticates the server supplied certificate. The net result, assuming all goes well, is that the public key contained in the X.509 certificate is safe (is trusted) and can be used to communicate with the defined entity (the Subject).
Servers typically only require their own certificate(s) and do not require root certificates - they simply send their certificates to the client and do not have to validate certificates. However TLS/SSL does allow mutual validation - both server and client send certificates. If client certificates are required in the application then the server is required to validate the client certificate and must be provisioned with all the required root and intermediate certificates by some out of band process - such as email or obtaining them from CA web sites.
Above is some basic and brief explain how the Certificate works and TLS/SSL works!for more detailed knowledge about those related with CA(Certificate Authority),Intermediate Authority,Registration Authority,Intermediate certificates,etc,you may try search and read in details from other related introductions.
- SSL certificate deployed at Official Website:www.mdidea.com
The official website https://www.mdidea.com deployed a GeoTrust® SSL certificate,which bring users secure connection and users can get security benefit from this SSL certificate.Using SSL security certifications ensures users around the globe will have their information and transactions protected on some certified and authenticated level.This is not only important for any financial transactions,but also for various types of user accounts and private access systems.
- SSL certificate deployed at Official Website:www.mdidea.net
The official mirror website https://www.mdidea.net deployed a Comodo®SSL certificate,which bring users secure connection and users can get security benefit from this SSL certificate,the Comodo SSL laid a purpose "Creating Trust Online",it provide an online user highest strength encryption,which means it provide visitor and clients very high safety level when you submit information,ask a question,or pay a product.The Comodo®SSL certificate also issued a COMODO SSL TrustLogo Badge.
- TLS/SSL certificate Verification:How To Verify HTTPS Certificates?
Hypertext Transport Protocol/Secure(HTTPS) is the backbone of internet security.It is a ubiquitious encryption that secures connections automatically.Users do not have to enable it,and the security it provides is strong.Most users blindly trust the green padlock in their address bar.You should always verify your connection is actually secure before inputting authentication credentials or financial information.When using tools like the Tor Browser this is especially relevant.It is also very important when using public Wi-Fi or other insecure wireless networks.This section provide some brief introduction on how to verify HTTPS certificates to ensure your connection is really secure:
View the Certificate:Begin by clicking the green padlock beside the URL bar which you are browsing.This will open a drop-down that provides some basic information about your connection.
Next,click the right arrow.
Click “More Information”.A new dialogue will open.Look at the “Technical Details”.The encryption protocol should be TLS 1.2(latest applicable version of TLS).SSL(Secure Sockets Layer) is an older protocol,the old version is not used by latest system.
Finally, click “View Certificate”. Another dialogue will open, showing you the specifics of the certificate.
Verify HTTPS Certificates:Cursory Inspection
There are three things to initially look for when verifying a certificate.
First,look at the Common Name.This should match the website you are visiting.For example,if you are visiting Bank of America’s website,the CN should be “www.bankofamerica.com”.You should be immediately suspicious if the CN does not match the website you are visiting.
Next,look at the Period of Validity.Most reputable Certificate Authorities(CA) only issue certificates for one year, though some now issue them for two or three.Be very wary if the certificate is valid for more than three years.
Finally,check out the Certificate Authority.There are a small number of reputable CAs.The most trusted and reputable are Comodo,GeoTrust,Avast,DigiCert,GoDaddy,Thawte,and Verisign.Do an internet search if you have questions about the validity of a CA.
Verify HTTPS Certificates:Detailed Inspection
You should do a more detailed inspection if any of the criteria liste above are suspect.You should also verify HTTPS certificates more fully if you are on an untrusted or insecure network.Untrusted networks include the Tor Network, and public Wi-Fi networks.Additionally,you should verify them anytime you are uncertain about your connection.Although this may seem like a lot of work, it is well worth it.
Scroll to the bottom on the certificate information and look at the fingerprints.Fingerprints are unique to their certificate,and are similiar to checksums.Like checksums,fingerprints need a known-good version for comparison,to ensure the fingerprint you see is the correct one.Therefore,we will use another website to find fingerprints for comparison.This website is at GRC fingerprinting site(https://www.grc.com/fingerprints.htm)
Navigate to the GRC fingerprinting site.In addition to some other popular websites,GRC will also display its own fingerprint at the top of the page.Next,scroll down to “Custom Site Fingerprinting”.Enter the URL to which your are browsing and click “Fingerprint Site”.
(The resulting page will display the authentic fingerprint,as retrieved by GRC.com.)
Compare this to the fingerprint your retrieved.If the two fingerprints match, you can go forward confidently with the knowledge that your connection is secure.
Since GRC has created HTTPS Fingerprints.This service will allows you to check whether or not there are MITM(man-in-the-middle) attack on the SSL/TLS secured site that you are trying to reach.It compares the certificate fingerprint to what you would receive to the fingerprint that they receive by going direct.If they are the same,the certificate is authentic and you have no problem.If they are different,then it is likely that someone is performing MITM(man-in-the-middle) attack on your SSL connection.This will help you care to check whether your SSL/TLS communications likely being compromised by a man-in-the-middle (MITM) attack or not.From viewpoints of SSL/TLS expert,it is "likely" because if you find a difference they could be generated for a number of ways:(1).Your SSL communications are being proxied by your enterprise;(2).You are under a legitimate MITM(man-in-the-middle) attack from a malicious group or hacker;(3).The website you tried to reach uses multiple certificates and the one you reached does not match the one that GRC reached.
In addition to all the other security tasks recommend,this may seem like a lot of work.Experts suggested it is not necessarily recommend you do this for every single website you visit,but recommend it for high-risk scenarios.Taking the time to verify HTTPS certificates gives you much more solid security than blindly trusting them.
- WebSiteRelated-FAQs 04.Exploring Suggestions For Worldwide Geographical Locations!
We provide Top Level IT Technology support for our herb fan friends in the global village from all parts of the world where has internet services!How to get the fastest exploring speed from your local network?Not sure which site connetion exploring faster for you?Below introduction results may useful for your exploring experiences reference,and we believe our smart herb fan friends has wisdom to choose one faster site for exploring:
Our art-level designed website https://www.mdidea.com is hosted with a trustworthy Apache Server in the Top Level Datacenter which located at East of North America,which brings visiting friends from nearby locations(North America,Central America,South America,Europe,Africa,Asia,Oceania.) the faster speed experience,and we has a tested result of the Geographical https Latency level show for reference shared with below table:
Geographical https Latency of mdidea.com[Result in Updating] Area: North America South America Europe Africa Asia Oceania Latency Vary Scope: 0.3
*Note: The smaller the Latency result in ms(millisecond),theoretically the faster connection speed you can reach. Geographical https Latency of mdidea.com VPsever in details of Tested Cities Area/Nation: North America/United States City: Albany Albuquerque Asheville Atlanta Austin Baltimore Latency Scope: ~ms ~ms ~ms ~17ms
~43.6ms ~ms City: Boston Buffalo Charlotte Chicago Cincinnati Cleveland Latency Scope: ~5.6ms ~ms ~21.4ms ~23.5ms
~ms ~ms City: Colorado Springs Columbus Dallas Denver Des Moines Detroit Latency Scope: ~ms ~24ms ~42ms
~47ms ~ms ~ms City: Green Bay Houston Jackson Jacksonville Kansas City Knoxville Latency Scope: ~ms ~ms ~ms ~ms ~45ms ~ms City: Las Vegas Los Angeles Louisville Manhattan Miami Minneapolis Latency Scope: ~ms ~67.3ms
~ms ~ms ~35ms
~ms City: Missoula Monticello New Orleans New York Oklahoma City Orlando Latency Scope: ~ms ~ms ~ms ~0.5ms
~ms ~31.9ms City: Philadelphia Phoenix Piscataway Portland Sacramento Salem Latency Scope: ~2.564ms
~ms ~ms ~ms ~ms City: Salt Lake City San Antonio San Diego San Francisco San Jose Seattle Latency Scope: ~73.6ms ~ms ~68.0ms ~76.5ms ~24ms ~67ms
City: South Bend St Louis Tampa Toledo Washington Boulder Latency Scope: ~ms ~29.9ms ~ms ~ms ~6ms ~ms City: Santa Clara Ashburn Pittsburgh Lenoir Nevada Arlington Latency Scope: ~14.3ms
~14.2ms ~ms ~ms ~ms City: Newark Sayreville Absecon Wichita Clarks Summit,PA Secaucus,NJ Latency Scope: ~ms ~ms ~ms ~ms ~6ms ~1.0ms City: Waco,TX New Jersey Texas Virginia Queretaro-MEX California-US Latency Scope: ~44ms ~1ms ~40ms ~6ms ~69ms ~74ms Area/Nation: North America/Canada,Costa Rica,Guatemala,Mexico,Panama City: Calgary Edmonton Halifax Montreal Toronto Vancouver Latency Scope: ~79.0ms ~ms ~ms ~9.1ms ~1.1ms
~69.1ms City: Winnipeg Heredia Guatemala Mexico Panama San Jose Latency Scope: ~ms ~ms ~ms ~ms ~68.2ms
~72.1ms Area/Nation: South America/Argentina,Brazil,Chile,Colombia,Peru City: Buenos Aires Joao Pessoa Sao Paulo Santiago Medellin Lima Latency Scope: ~150.1ms ~ms ~127.6ms
~ms ~ms ~ms City: Porto Alegre Rio de Janeiro Santa Fe de la Vera Cruz Latency Scope: ~141.6ms ~133.5ms ~180ms ~ms ~ms ~ms Area/Nation: Europe/Austria,Belgium,Bulgaria,Czech Republic,Denmark,Estonia. City: Vienna Bruges Varna Prague Copenhagen Tallinn Latency Scope: ~101ms ~ms ~ms ~107.3ms ~81.3ms
~ms City: Antwerp Sofia Cologne Brussels Habry Latency Scope: ~75.8ms ~127.6ms ~ms ~79ms ~ms ~ms Area/Nation: Europe/Finland,France,Germany,Greece. City: Helsinki Paris Roubaix Berlin Frankfurt Thessaloniki Latency Scope: ~ms ~87ms ~72.1ms
~ms City: Tampere Dusseldorf Munich Haina Cologne Lille Latency Scope: ~103.4ms ~79.1ms ~83
~77.9ms Area/Nation: Europe/Hungary,Iceland,Ireland,Italy,Latvia,Lithuania. City: Budapest Reykjavik Newmarket Milan Riga Siauliai Latency Scope: ~108.5ms ~ms ~ms ~87.9ms
~ms ~ms City: Dublin Athens Padova Vilnius Rome Massa Latency Scope: ~80ms
~ms ~98.6ms ~106.1ms
~ms ~ms City: Trevi Milano Latency Scope: ~ms ~96ms ~ms ~ms ~ms ~ms Area/Nation: Europe/Luxembourg,Moldova,Netherlands,Norway,Poland. City: Luxembourg Chisinau Amsterdam Bergen Oslo Warsaw Latency Scope: ~ms ~ms ~73.9ms
~ms ~108.3ms ~97ms
City: Groningen Gdansk Rotterdam Dronten Katowice Meppel Latency Scope: ~91.1ms ~114.4ms ~77ms ~73ms ~107ms ~75ms Area/Nation: Europe/Portugal,Romania,Russia,Slovenia,Sweden,Switzerland,Serbia. City: Lisbon Bucharest Moscow Ljubljana Stockholm Zurich Latency Scope: ~106.7ms ~111ms
City: Geneva St.Petersburg Belgrade Constanta Lausanne Kazan Latency Scope: ~86.2ms ~108
~95.8ms ~145ms Area/Nation: Europe/Spain,Turkey,Ukraine,England Republic. City: Barcelona Madrid Valencia Istanbul Kiev London Latency Scope: ~96.8ms
City: Manchester Newcastle Glasgow Kharkov Bridgend Fareham Latency Scope: ~74.5ms ~ms ~ms ~130.1ms ~ms ~72.9ms
City: Kharkiv Latency Scope: ~124ms
~ms ~ms ~ms ~ms ~73.2ms Area/Nation: Africa/Egypt,Kenya,Morocco,South Africa,Tanzania,Uganda. City: Cairo Nairobi Fez Cape Town Dar es Salaam Kampala Latency Scope: ~129.6ms ~ms ~226.9ms ~ms ~ms ~ms City: Johannesburg Durban Latency Scope: ~244.1ms ~255.2ms ~ms ~ms ~ms ~ms Area/Nation: Asia/China,India City: Hong Kong ShangHai Hangzhou Chennai Hyderabad New Delhi Latency Scope: ~215.9ms
~227.4ms ~254.9ms ~252.6ms ~223.2ms ~213.1ms
City: Mumbai Bangalore Latency Scope: ~186.9
~ms ~ms ~ms ~ms Area/Nation: Asia/Indonesia,Israel,Malaysia,Pakistan,Philippines,Singapore City: Jakarta Tel Aviv Kuala Lumpur Karachi Manila Singapore Latency Scope: ~258.5ms ~165ms ~250.6ms
~.0ms ~.0ms ~239
City: Kiryat-Matalon Latency Scope: ~138.7ms ~ms ~ms ~ms ~ms ~ms Area/Nation: Asia/Iran, City: Tehran Latency Scope: 193~349ms ~ms ~ms ~ms ~ms ~ms Area/Nation: Asia/Saudi Arabia,Thailand,United Arab Emirates,Vietnam, City: Riyadh Bangkok Dubai Hanoi Latency Scope: ~155.4ms ~270.9ms
~195.3ms ~ms ~ms ~ms Area/Nation: Oceania/Australia,New Zealand. City: Adelaide Brisbane Melbourne Sydney Christchurch Perth Latency Scope: ~256.6ms ~271.2ms ~233.2ms ~233.2ms ~196.1ms ~285ms City: Auckland Latency Scope: ~194ms ~ms ~ms ~ms ~ms ~ms Area/Nation: Other City:in testing... City: Latency Scope: ~ms ~ms ~ms ~ms ~ms ~ms
The mirror website https://www.mdidea.net is hosted with a trustworthy Advanced Apache Server located in a Green Energy Datacenter with Highest Technological Standards which located at Middle of the Europe Continent,help managed with a First Class Hosting Company which running high performance VPserver based on First Class Hardware,Software and Infrastructure,togethor with the high availability and speed brings visiting friends from nearby locations(Europe,Africa,Asia,North America,South America,Oceania) the stable and faster speed experience,and we has a tested result of the Geographical https Latency level show for reference shared with below table:
Geographical https Latency of mdidea.net Area: Europe Asia Africa North America South America Oceania Latency Vary Scope: 1.7~3.9
*Note: The smaller the Latency result in ms(millisecond),theoretically the faster connection speed you can reach. Geographical https Latency of mdidea.net VPsever in details of Tested Cities Area/Nation: Europe/Austria,Belgium,Bulgaria,Czech Republic,Denmark,Estonia. City: Vienna Bruges Varna Prague Copenhagen Tallinn Latency Scope: ~26ms
~ms ~ms ~18.7ms ~17ms
~ms City: Antwerp Sofia Cologne Brussels Habry Falkenstein Latency Scope: ~2.2ms ~31ms
~ms ~2ms ~ms ~13ms Area/Nation: Europe/Finland,France,Germany,Greece. City: Helsinki Paris Roubaix Berlin Frankfurt Thessaloniki Latency Scope: ~30ms ~15ms ~ms ~13ms
~ms City: Tampere Dusseldorf Munich Haina Strasbourg Latency Scope: ~33ms ~ms ~18ms ~ms ~18ms ~ms City: Nuremberg Patras Cologne Lille Latency Scope: ~13ms ~40ms ~18.2ms ~14.9ms ~ms ~ms Area/Nation: Europe/Hungary,Iceland,Ireland,Italy,Latvia,Lithuania. City: Budapest Reykjavik Newmarket Milan Riga Siauliai Latency Scope: ~26ms ~ms ~ms ~17ms
~ms ~ms City: Dublin Athens Padova Vilnius Rome Massa Latency Scope: ~17ms
~ms ~27ms ~36.6ms
~32.5ms ~ms City: Trevi Brescia Latency Scope: ~ms ~35ms ~ms ~ms ~ms ~ms Area/Nation: Europe/Luxembourg,Moldova,Netherlands,Norway,Poland. City: Luxembourg Chisinau Amsterdam Bergen Oslo Warsaw Latency Scope: ~10ms ~ms ~1.8ms
~ms ~ms ~27ms
City: Groningen Gdansk Rotterdam Dronten Meppel Latency Scope: ~5.1ms ~34ms ~4ms ~2ms ~4ms ~ms Area/Nation: Europe/Portugal,Romania,Russia,Slovenia,Sweden,Switzerland,Serbia. City: Lisbon Bucharest Moscow Ljubljana Stockholm Zurich Latency Scope: ~48ms ~41ms
~44ms ~ms ~22.6ms
City: Geneva St.Petersburg Belgrade Kazan Yekaterinburg Novosibirsk Latency Scope: ~27.4ms ~39ms
~ms ~68ms ~77ms ~107ms City: Vladivostok Latency Scope: ~106ms ~ms ~ms ~ms ~ms ~ms Area/Nation: Europe/Spain,Turkey,Ukraine,United Kingdom. City: Barcelona Madrid Valencia Istanbul Kiev London Latency Scope: ~39ms ~ms ~ms ~49
City: Manchester Newcastle Glasgow Kharkov Bridgend Edinburgh Latency Scope: ~14ms ~ms ~ms ~43ms
City: Mykolaiv Latency Scope: ~45ms ~ms ~ms ~ms ~
~ms Area/Nation: Asia/China,India City: Hangzhou Hong Kong Shanghai Chennai Hyderabad New Delhi Latency Scope: ~273ms ~255ms
~176ms ~ms ~136ms City: Mumbai Bengaluru Latency Scope: ~115ms
~ms ~ms ~ms ~ms Area/Nation: Asia/Indonesia,Israel,Malaysia,Pakistan,Philippines,Singapore City: Jakarta Tel Aviv Malaysia Karachi Manila Singapore Latency Scope: ~217.8ms ~ms ~184ms ~ms ~ms ~183ms
Area/Nation: Asia/Saudi Arabia,Thailand,United Arab Emirates,Vietnam,Kazakhstan City: Riyadh Bangkok Dubai Hanoi Ho Chi Minh City Latency Scope: ~142ms ~158ms
~ms ~274ms ~ms Area/Nation: Asia/Kazakhstan,Iran City: Almaty Tehran Latency Scope: ~111ms ~123ms ~ms ~ms ~ms ~ms Area/Nation: Africa/Egypt,Kenya,Morocco,South Africa,Tanzania,Uganda. City: Cairo Nairobi Fez Cape Town Dar es Salaam Kampala Latency Scope: ~64ms ~179ms ~ms ~ms ~ms ~ms City: Johannesburg Durban Tel Aviv Latency Scope: ~176ms
~186ms ~77ms ~ms ~ms ~ms Area/Nation: North America/United States City: Albany Albuquerque Asheville Atlanta Austin Baltimore Latency Scope: ~ms ~ms ~ms ~93ms ~
~ms City: Boston Buffalo Charlotte Chicago Cincinnati Cleveland Latency Scope: ~90ms ~ms ~ms ~90ms
~ms ~ms City: Colorado Springs Columbus Dallas Denver Des Moines Detroit Latency Scope: ~ms ~ms ~112ms
~120ms ~ms ~ms City: Green Bay Houston Jackson Jacksonville Kansas City Knoxville Latency Scope: ~ms ~ms ~ms ~ms ~109ms ~ms City: Las Vegas Los Angeles Louisville Manhattan Miami Minneapolis Latency Scope: ~ms ~154ms
~ms ~ms ~110ms
~ms City: Missoula Monticello New Orleans New York Oklahoma City Orlando Latency Scope: ~ms ~ms ~ms ~79.8ms
City: Philadelphia Phoenix Piscataway Portland Sacramento Salem Latency Scope: ~ms ~132ms
~ms ~ms ~ms ~ms City: Salt Lake City San Antonio San Diego San Francisco San Jose Seattle Latency Scope: ~129ms ~ms ~
~ms ~98ms ~144ms City: South Bend St Louis Tampa Toledo Washington Boulder Latency Scope: ~ms ~105ms ~ms ~ms ~91ms ~128ms City: Santa Clara Ashburn Pittsburgh Lenoir Nevada Arlington Latency Scope: ~160ms ~85.9ms ~ms ~ms ~ms ~ms City: Newark Sayreville Absecon Wichita California New Jersey Latency Scope: ~ms ~ms ~ms ~ms ~150ms ~97ms City: Texas Virginia Waco,TX Lansing,MI Clarks Summit,PA Latency Scope: ~120ms ~86ms ~117ms ~105ms ~83ms ~ms Area/Nation: North America/Canada,Costa Rica,Guatemala,Mexico,Panama City: Calgary Edmonton Halifax Montreal Toronto Vancouver Latency Scope: ~ms ~ms ~ms ~86ms
~107ms ~172ms City: Winnipeg Heredia Guatemala Mexico Panama San Jose Latency Scope: ~ms ~ms ~ms ~95ms ~174ms ~ms City: Queretaro San Jose Latency Scope: ~192ms ~165ms ~ms ~ms ~ms ~ms Area/Nation: South America/Argentina,Brazil,Chile,Colombia,Peru City: Buenos Aires Joao Pessoa Sao Paulo Santiago Medellin Lima Latency Scope: ~249ms ~ms ~215ms ~ms ~ms ~ms City: Porto Alegre Rio de Janeiro Santa Fe de la Vera Cruz Latency Scope: ~248ms ~215ms
~262ms ~ms ~ms ~ms Area/Nation: Oceania/Australia,New Zealand. City: Adelaide Brisbane Melbourne Sydney Christchurch Perth Latency Scope: ~ms ~371ms ~304ms
~ms ~337ms City: Auckland Latency Scope: ~262ms ~ms ~ms ~ms ~ms ~ms Area/Nation: Other City:in testing... City: Latency Scope: ~ms ~ms ~ms ~ms ~ms ~ms
♥The electronic data information published at our official website www.mdidea.com and www.mdidea.net,help our clients more clear about common support tips,frequently asked questions,order procedure tips and additional explanation related.
♣ last update date: