Best Practices for Security & Privacy
本文讨论如何保证你的app的数据安全
Security Tips
如何执行各种任务，以及如何保证你的app的数据和用户的数据安全。
Security with HTTPS and SSL
如何确保你的app执行网络操作是安全的。
Developing for Enterprise
对于企业级app，如何实现设备管理策略。——Enhancing Security with Device Management Policies
Security Tips
Android有内置于操作系统的安全功能，这显著降低了app安全问题的频率和影响。Anroid系统如此设计，因此，你能基于默认的操作系统和文件权限开发你的app，而不必太多的考虑你的app的安全问题。
帮助你构建安全的app的一些核心的安全功能包括：
- The Android Application Sandbox，Android Application 沙箱能把你的app的数据和代码执行与其他的app隔离开来。
- application framework提供了通用安全功能的强大而稳定的实现，例如加密、权限和安全的IPC（进程间通信）。
- 像ASLR、NX、Propolice、safe_iop、OpenBSD dlmalloc、OpenBSD calloc和Linux mmap_min_addr等这些技术来降低安全风险和通用的内存管理错误。
- 加密文件系统防止设备上的数据丢失或被盗。
- 用户授权机制以限制对系统功能和用户数据的访问。
- 应用程序定义的权限来控制基于每个app上的application数据。
然而，熟悉本文给出的Android安全实践和建议也是十分重要。遵循下面的实践建议作为平时的编码习惯将减少无意中引入的对你的用户产生不利影响的安全问题。
Storing Data
Android系统上的app共同的最受关注的安全问题你的app保存在设备上的数据是否能被其他app访问。在Android设备上保存数据有如下三种方式：
Using internal storage
默认地，你在内部存储器（internal storage）产生的文件仅仅能被你的app访问。这种保护机制是由Android实现的，对几乎所有的application都是有效的。
一般地，对于IPC文件，你应该不使用MODE_WORLD_WRITEABLE 或者 MODE_WORLD_READABLE 模式。因为它们并没有提供特殊应用对数据访问的限制的能力，也没有提供对数据格式进行控制。如果你想和其他的app进程分享数据，你可以考虑使用content provider，其对其他的app提供了读和写权限，并且能基于特定情况进行动态授权。
为了对敏感数据进行额外的保护，你可以选择使用一个你的app不能直接访问的key加密本地文件。例如，key能放在KeyStore 里，并且有密码保护，而密码不保存在设备上。由于能监视用户输入密码，这并没有从根本上保护数据，但是当设备丢失时，对没有文件系统加密（file system encryption）时，数据能被保护。
Using external storage
产生在外部存储（ external storage）上的文件，例如SD卡，是全局可读写的。因为外部存储能被用户移除，也能被任何app修改，你不应该使用外部存储存储敏感信息。
像任何来自于不可信任源的数据时，当处理来自于外部存储的数据时你应该执行输入验证（perform input validation ）。我们强烈地建议在动态加载之前你不要在外部存储上存储可执行文件或者class文件。如果你确要从外部存储检索可执行文件，在动态加载之前文件应该被签名和密码验证。
Using content providers
Content providers提供结构化存储机制。其能限制和保护你自己的app，或者对其他的app提供可访问接口。如果你不想要其他的app访问你的ContentProvider，在app的manifest文件里声明为android:exported=false 。反之，设置android:exported属性为“true”以允许其他app访问存储数据。
当产生一个能被其他app访问的ContentProvider时，你能在功能清单文件里指定一个读和写的权限（permission ），或者分开指定读和写的权限。我们建议你限定权限到那些要求完成手边任务的权限上。记住：比起打破已有用户、把用户逼走，为了为用户添加新的功能在以后添加权限对用户来说通常更容易更可接受。
如果你仅仅在你自己的apps之间通过content provider共享数据，使用android:protectionLevel属性设置
成"signature"保护是更好的。签名权限不需要用户确认，因此当app通过content provider访问被相同的key signed的数据时它们提供了更好的用户体验，更好的访问控制。
content provider也能提供更小粒度的访问控制，通过声明android:grantUriPermissions属性，并使用在intent对象里的FLAG_GRANT_READ_URI_PERMISSION和FLAG_GRANT_WRITE_URI_PERMISSION标志来做访问控制。这些权限范围通过 <grant-uri-permission element>能更近一步限定。
当访问congtent provider时，使用参数化的查询方法例如query()、update()和delete()以避免来自不信任源的潜在的SQL注入。注意如果selection参数在提交它给方法之前通过和用户数据拼接而构建时，使用参数化方法是不够的。
对于写权限不要有一种错误的安全感。Consider that the write permission allows SQL statements which make it possible for some data to be confirmed using creative WHERE clauses and parsing the results。例如，一个黑客可能在通话记录里试探某个电话号码是否存在。只要这个电话号码已存在，他可以通过修改一行来探测。
如果content provider数据具有可预测的结构，写权限可能等同于提供了读和写权限。
Using Permissions
因为Android的“沙箱”机制隔离把app彼此隔离开来，app必须明确地共享资源和数据。android通过权限声明来做到这一点。app需要这些权限来获取额外的不被基本的sandbox提供的能力，包括访问设备特性，例如照相机。
Requesting Permissions
我们推荐你的app最下化声明权限的个数，这样能提高用户对你的pp的可接受度，并且使你的app减少黑客袭击。最小化权限声明、不使用敏感权限能减少无意中滥用这些权限的风险。
如果能设计你的app确保功能实现的情况下不需要任何权限，这是最完美的。例如， rather than requesting access to device information to create a unique identifier, create a GUID for your application (see the section about Handling User Data). Or, rather than using external storage (which requires permission), store data on the internal storage.
除了使用<permissions>节点请求权限，你也能使用<permissions>来保护IPC（进程间通信）。IPC是安全敏感的，并且会暴露给其他的app，例如像ContentProvider。一般地，相比于用户确定权限声明，我们推荐使用其他的访问控制，因为权限可能使用户混淆和迷惑。例如，对于属于同一个开放者的一组apps之间，在IPC通信间考虑使用signature protection level权限控制。
不要泄漏权限保护的数据。这通常发生在通过IPC暴露你的app数据时。IPC通信机制一定要求你声明和获取特定的权限，但是不要请求任何客户端的IPC接口的权限。关于更多潜在的影响详情，以及这种类型问题的频率在 USENIX: http://www.cs.be rkeley.edu/~afelt/felt_usenixsec2011.pdf发表在上的论文里有讨论。
Creating Permissions
一般地，你应该努力定义尽可能少的权限来满足你的安全需求。大多数app都不需要产生新的自定义的权限，因为系统定义的权限几乎覆盖了所有的情况。大多数情况下，进行访问检查和权限控制使用已存在的权限。
如果你必须产生一个新权限，首先考虑使用 "signature" protection level是否能满足你的访问控制要求。签名权限对用户来说是透明的，仅仅在当app执行许可检查时，同一个开放者的相同签名的apps才被允许访问。
如果你使用"dangerous" protection level产生一个权限，有许多较复杂的地方需要考虑：
- 权限必须要求有一个字符串，该字符串简明地告诉用户需要的安全权限，用户决定是否继续。
- 该权限字符串必须国际化以满足不同的语言。
- 用户可能被权限迷惑或者觉得是潜在风险而选择不安装app
- 当权限的产生者还没有安装时app就请求了权限。
如上这些需考虑的地方给作为开发者的你展示了显著的非技术挑战，同时也让用户感到困惑，这即是为什么我们不鼓励"dangerous" permission level的使用。
Using Networking
网络事务根本上是安全的风险，因为它涉及发送用户私有数据。人们正日益意识到移动设备的隐私问题，特别地当设备执行网络操作时。因此，你的app以最优的方式在任何时候都能保护用户的数据安全是十分重要的。
Using IP Networking
在Android上的网络相比于其他的Linux环境来说，并没有特别的不同。最关键点是确保对于敏感的数据使用合适的协议，例如HttpsURLConnection 用于安全的web流。只要服务器端支持HTTPS，比起HTTP我们更倾向使用HTTPS。因为移动设备频繁的链接到网络，而这些网络又是不安全的，例如公共的Wi-Fi热点。
有身份验证的，socket层加密的通信使用SSLSocket类可以很容易的实现。考虑到Android设备通过Wi-Fi链接到不安全的无线网络的频率，强烈的推荐所有有网络请求的apps使用安全的网络链接。
我们看到有些app使用localhost网络端口处理敏感的IPC。我们不鼓励这种方式，因为这些接口也能被设备上的其他app访问。因此，你应该使用Android IPC机制，该机制能保证身份验证，例如 Service。比起使用回环，更糟糕的方式是使用绑定到的INADDR_ANY，因为那么你的app可能从任何地方接收请求。
此外，一个老生常谈的常见的问题是确保您不信任来自HTTP或其他不安全的协议下载的数据。这包括在WebView 里的输入验证和来自HTTP的任何响应。
Using Telephony Networking
SMS协议主要设计用于user-to-user通信，对想要传输数据的app不是很合适。由于SMS的局限，我们强烈地推荐使用 Google Cloud Messaging（GCM）和IP网络来从一个web服务器发送数据消息到用户设备上的app。
注意SMS在网络和设备上既不是加密的也不是很强身份验证的。特别地，任何SMS接收者应该遇到过恶意用户可能向你的app发送SMS——不要依赖不可靠的SMS数据执行敏感命令。还有，你应该知道SMS可能在网路上遭到篡改和拦截。Android设备上，SMS消息通过广播意图来发送，因此SMS可能被声明了READ_SMS 权限的app捕获和读取。
Performing Input Validation
缺乏输入验证是影响app的最通用的安全问题之一，不管你的app运行在什么平台上都存在这个问题。Android已做了平台级措施来减少app输入验证问题的暴露，你应该尽可能的使用这些特性和策略。还要注意选择类型安全的预研也能减少输入验证问题的可能性。
如果你使用native代码，任何来自于文件、网络和IPC的数据都有引入安全问题的风险。最通用的问题有 buffer overflows, use after free和off-by-one errors。Android提供了许多技术—例如ASLR和DEP—减少产生这些错误的可能性，但它们并没有解决这些突出问题。你能通过认真的处理指针和管理缓冲区来避免这些问题。
还有，像JavaScript和SQL这些基于字符串的语言由于转义字符和 script injection也可能遭遇输入验证问题。
如果你向SQL数据库或者content provider提交了数据查询请求，SQL注入可能是一个问题。解决该问题最后的方式是使用参数化查询，这在上面章节讲content providers时有所讨论。限定权限为只读或者只写权限也能减少潜在的SQL注入相关的安全问题。
如果你不能使用上面的安全相关建议，我们强烈地推荐使用格式良好的结构化数据，并且与期望格式数据的一致性检查。然而，字符黑名单或者字符替换可能是有效的策略，这些技术在实践中被证明是错误的，应该尽可能避免。
Handling User Data
一般地，保护用户数据安全的最好方式是尽可能少的使用访问用户敏感和个人数据的API。如果你不得不使用用户数据，如果能避免存储或者传递个人数据信息，就不要存储和传递用户数据。最后，考虑是否可以使用哈希或者不可逆的数据形式来实现你的app的业务逻辑。例如，你可以使用一个email地址哈希后作为主键，而不传输或者存储email地址。这减少了不慎泄漏数据的几率，这也减少了黑客袭击你的app的机会。
如果你的app需要使用到个人信息例如密码或者用户名，记住某些法律许可或者条款需要您提供隐私政策来解释你使用和存储这些数据。因此遵循最小化访问用户数据的安全实践可能是最简单的措施和规则。
你也要考虑你的app是否无意中给其他部分暴露了个人信息，例如给第三方广告或者服务组件。如果你不知道一个组件或者服务为什么要求个人数据，不要提供给它提供个人数据。一般地，减少对个人信息的访问将减少这方面潜在的问题。
如果必须要访问敏感数据，评估信息是否必须要上传到服务器，或者是否可以在客户端执行这些操作。考虑使用敏感数据的代码仅在客户端执行以避免传输用户数据。
还有，确保你不要无意中由于过份的IPC许可、全局可写的文件或者网络socket而暴露你的用户数据给设备上的其他app。泄漏权限保护数据将在Requesting Permissions部分专门讨论。
如果GUID被要求，产生一个大的，唯一的数存储它。不要使用电话标识符例如电话号码或者IMEI，因为这些数据可能会暴露个人信息。这个主题更多的信息将在 Android Developer Blog.里讨论。
注意在Android上写设备端log时，logs是共享资源，对有READ_LOGS 权限的app是可访问的。虽然phone日志数据是临时的，并且在重启时删除，不合适的打印用户信息日志也可能无意中泄漏用户数据给其他的app。
Using WebView
因为WebView消费web内容，这些内容可能包括HTML和JavaScript，不合适的使用可能引入通用的web安全问题，像ross-site-scripting （JavaScript注入）。Android有许多机制减少这些潜在问题的范围，如通过限制WebView的某些功能的使用以最小化满足你的app的功能。
如果你的app不需要在WebView里直接使用JavaScript，不要调用setJavaScriptEnabled()。一些实例代码使用这个方法，你可能会在这些代码上借鉴或者修改这些代码以为你的app所用，如果你的app不需要，移除该方法的调用。默认地，WebView并不执行JavaScript，因此跨站脚本攻击是不可能的。
使用addJavaScriptInterface() 方法时要特别注意，因为它允许JavaScript调用app里的普通的java操作方法。如果你使用它，暴露addJavaScriptInterface()给仅仅所有的输入是可信的web页。如果不可信的输入被允许，不可信的JavaScript可能能调用你的app里的Android方法。一般地，我们推荐仅仅addJavaScriptInterface() 暴露给包含在的app的APK里的JavaScript。
如果你的app在WebView里访问敏感数据，你可能需要使用clearCache() 方法删除存储在本地的任何文件。服务器端头字段例如no-cache也能被用于标识app不应该缓存特别的内容。
Handling Credentials
一般地，我们推荐最小化请求用户证书的频率，最好不要使用——为了使钓鱼攻击更明显，更不容易成功。推荐使用一个用户授权token并刷新它。
不管什么情况下，用户名和密码都不要存储在设备上。相反，使用由用户提供的用户名和密码，执行初始认证，然后用一个短暂的，特定服务的授权令牌。
能被多个app使用和访问的Service应该能被AccountManager.访问和使用。如果可能，使用AccountManager类调用云端Service，并且不要在设备上存储密码。
使用AccountManager检索一个Account后，CREATOR在传给任何证书之前，这样你不可能传递证书给错误的app。
如果证书仅仅被你产生的app使用，那么你能验证app通过AccountManager使用checkSignature()方法。另外，如果仅仅一个app将使用该证书，你能使用 KeyStore存储该证书。
Using Cryptography
除了提供数据隔离，支持全文件系统加密和提供安全通信渠道，Android提供了各种的算法通过加密保护数据。
一般地，尽可能使用高水平的已存在的能满足你的业务关切的实现框架。如果你需要从一个你知道的位置安全地检索一个文件，一个简单的HTPPS URI能满足你的需求，而不需要你熟知密码学。如果你需要一个安全通道，可以考虑使用HttpsURLConnection 或者SSLSocket，而不是自己写协议。
如果你发现你确实需要自己实现协议，我们强烈地推荐你不要使用自己实现的加密算法。使用存在的加密算法例如AES或者RSA，这些算法实现在Cipher 类里有提供。
使用一个安全的随机数产生器，SecureRandom，去初始化加密keys,KeyGenerator。使用非安全随机数产生器产生的key显著地消弱了加密算法的强度，可能产生离线袭击。
如果你需要存储一个key以重复使用，使用像KeyStore这样的机制，它提供了长期存储和检索加密key的机制。
Using Interprocess Communication
一些app企图使用像网络套接字和共享文件这样的传统的Linux技术来实现IPC。我们不推荐你这样做，我们强烈地推荐你使用Android系统提供的功能实现IPC，例如 Intent、Binder或者Messenger配合着Service或者BroadcastReceiver使用。Android IPC机制允许你验证链接到你的IPC的app的一致性，并且设置每一个IPC机制的安全策略。
一些安全元素能在IPC机制间共享。如果你的IPC机制是不打算给其他的app使用，在组件的manifest元素里设置 android:exported 属性为"false"，例如对于<service>元素。这对于在同一个UID里的由多个进程组成的app是很有用的，或者你写到最后，你发现你事实上你不需要通过IPC暴露功能给其他的app，你又不想重写代码，这样你只需简单的在manifest里设置该属性为false。
如果你的IPC想要被其他的app访问，你能使用<permission>元素作为一个安全策略。如果你的IPC用于你的使用相同key签名的各个app之间，更偏向于使用android:protectionLevel来实现"signature"级权限。
Using intents
在Android里意图是更好的异步IPC机制。取决于你的app需求，你能使用sendBroadcast()或者sendOrderedBroadcast()或者一个显示意图来启动一个专门的app组件。
注意有序广播可能被一个接收者消费和终结，因此它们可能不被投递到所有的apps。如果你需要投递一个确保到某个接收者的意图，那么你必须使用一个声明了接收者的显式意图。
意图发送者能指定接收者要有一个非空权限，并在方法调用里验证该权限。仅仅有该权限的app能收到该意图。如果在一个广播意图里的数据是敏感的，你应该考虑使用一个权限来保证恶意app不能注册和接收没有相应权限的广播。这些情况下，你能考虑直接调用接收者，而不是发起一个广播。
注：意图过滤器不应该考虑作为安全特性——组件能通过显式意图来调用，可能没有符合意图过滤器的数据。你应该在你的意图接收者里执行输入验证来确定对于被调用的广播接收者、service或者activity来说是合适的数据格式。
Using services
Service 常常被用于提供功能给其他的app使用。每一个service类必须在manifest文件里有相应的声明。
默认地，services不要exported，不能被其他的app调用。然而，如果你给你的Servcie声明添加任何意图过滤器，那么默认是exported。因此，最好清晰地声明android:exported属性来明确serivce的行为是你想要的。Services也能使用android:permission属性来保护。如此做，其他的app将需要在它们的自己的manifest里声明相应的<uses-permission>元素来确保能开启、停止或者绑定service。
Service能使用权限来保护调用自己的IPC调用，在执行调用实现之前调用checkCallingPermission() 方法来实现。我们推荐在manifest使用声明的权限，因为这些不容易被检测到。
Using binder and messenger interfaces
在Android里使用Binder 或者Messenger是更好的RPC风格的IPC机制。它们提供了定义良好的接口来保证接入点间的相互认真，如果需要。
我们强烈里推荐设计不需要做权限检查业务的接口。Binder 或者Messenger对象不需要在app的manifest文件里进行声明。因此你不能直接在这些对象上使用声明权限。这些对象继承了实现自己的Service或者activity在manifest里声明的权限。如果你实现了一个要求认证和访问控制的接口，这些控制必须明晰地在 Binder或者Messenger通过代码实现。
如果提供不需要访问控制的接口，使用checkCallingPermission()验证调用着是否有所需的权限。在访问一个service之前这是特别重要的，因为你的app标识可能传递给其他的app接口。如果调用一个service提供的接口，如果你没有访问被给service的权限，bindService()回调可能失败。如果调用你自己的app提供的接口，可以使用 clearCallingIdentity()满足app内部的安全检查。
关于在Service里执行IPC的更多信息，参见Bound Services。
Using broadcast receivers
BroadcastReceiver 处理Intent初始化的异步请求。
默认地，广播接收着是exported的，并且能被其他的app调用。如果你的BroadcastReceiver 是打算给其他的app使用，你可能需要在manifest文件的<receiver> 元素中使用安全权限。这将阻止没有相应权限的app给 BroadcastReceiver发送意图
Dynamically Loading Code
我们强烈地不建议加载你的app APK之外的代码。这样做由于代码注入和代码捕获显著地增加了app受威胁的风险。这也增加了app版本管理和测试的复杂性。最后，这也使得验证app行为变得不可能，因为这在一些环境里可能被禁止。
如果你的app确实要动态加载代码，记住关于动态加载代码最重要的方式是它必须和app APK运行有相同的安全权限。用户基于你的标识和描述决定是否安装你的app，这些给用户的知会表明了你提供了运行在app上的代码，包括动态加载的代码。
动态加载代码最主要的安全风险是代码需要来自于可信的源。如果模块直接包括在你的APK里，那么它们不能被其他的app修正。不管这些代码是native库还是使用DexClassLoader加载的类，这都是对的。我们已看到过一些app企图从不安全的地方加载代码的实例，例如通过非加密的协议从网络下载代码或者从外部存储这样全局可写的地方。这些地方可能导致某些人通过网络篡改传输的数据，或者用户设备上的其他app修改存储在设备上的数据。
Security in a Virtual Machine
Dalvik是Android的运行时虚拟机（VM）。Dalvik是专门为Android设计的，但一些其他虚拟机对代码安全的关注也用到了Android上。一般地，你自己不需要关注与虚拟机相关的安全问题。你的app运行在一个安全的沙箱环境里，因此系统里其他的进程不能访问你的代码或者私有数据。
如果你对深挖虚拟机安全这方法的知识感兴趣，我们推挤你自学这方面一些已存在的文档。较好的两个文档资源如下：
本文主要关注于Android于其他的VM环境相比有那些特有的特性和不同点。对于在其他的环境有VM编程经验的开发着来说，写Android App有两点主要不同的地方值得关注。
- 一些虚拟机，例如JVM或.net运行时，扮演安全边界的角色，从底层操作系统功能隔离代码。Android上，Dalvik VM不是一个安全边界——app 沙箱在OS级上实现，因此Dalvik能和同一个app的native代码进行互操作，而没有任何安全限制。
- 考虑到移动设备上有限的存储空间，普遍地，开发者可能想要构建模块app，并使用动态类加载。当这样做的时候，要考虑安全因素—你从哪检索你的app逻辑代码和你本地哪儿存储。不要从未验证的源处使用动态代码，例如不安全的网络源或者外部存储，因为代码可能由于恶意的行为而被修改。
Security in Native Code
一般地，我们鼓励开发者使用Android SDK来进行app开发。而不是使用Android NDK来开发native代码。使用native代码开放的app将更加复杂，移植性差，并且更可能产生通用的内存崩溃错误例如缓存溢出。
Android使用Linux内核来实现的，如果你想要使用native代码，熟悉使用Linux开发安全实践是特别有用的。Linux安全开发实践超出本文所讲范围，但最受欢迎的相关资源是“Secure Programming for Linux and Unix HOWTO”，参见http://www.dwheeler.com/secure-programs。
Android和Linux环境之间最重要的不同点是Application Sandbox。在Android上，所有的app都运行在Application沙箱里，包括那些native代码。与Linux类比，开发者可以简单地认为是如同给每个app一个有有限权限的独一无二的UID。更详细的讨论参见 Android Security Overview，你也应该对app权限机制比较熟悉，即使你编写native代码。
Security with HTTPS and SSL
安全的Sockets层（Secure Sockets Layer ：SSL）——现在技术上被成为Transport Layer Security (TLS)——是为了在客户端和服务器端加进行加密通信的通用的构建模块。app不正确的使用SSL可能导致通过网络传输的app数据被恶意拦截。为了确保这不发生在你的app上，本文主要讲述了使用安全网络协议可能碰到的常见的陷阱，并表明了对使用Public-Key Infrastructure (PKI)更大的关切。
Concepts
一个典型的SSL使用图景是服务器端有通过公共的key和私有key进行匹配的验证。作为一个SSL客户端和服务器端进行握手的一部分，服务器端提供给客户端使用 public-key cryptography进行签名验证的私有key。
然而，任何人都能产生属于自己的证书和私有key。因此一个简单的握手除了能证明服务器知道与公钥相匹配的私钥外并不能证明任何其他的事情。解决该问题的一种方法是让客户端有一个或者多个它信任的证书集合。如果该证书不在该集合里，服务器将是不可信的。
这种简单方式有几个小缺点。随着时间的推移服务器应该能升级到更强的key（"key rotation"）,用新的公钥取代证书里的原有的公钥。 不幸地，这时由于服务器端配置的改变，客户端必须进行升级。这将是有问题的，如果服务器不在应用开发者的控制下，例如，可能是一个第三方web Service。这种方法也有问题，如果app需要能和任意服务器例如web浏览器或者email app进行交互。
为了解决这些问题，服务器配置有从称为数字证书机构（Certificate Authorities (CAs)）发行的证书。宿主平台包含了可信的CA列表。像Android 4.2（Jelly Bean），Android当前包含了超过100个CAs，这些CAs将会在每次发布时被更新。与Server端相似，一个CA有一个证书和私钥。当发布一个CA给服务器的时候，CA使用它的私钥签名服务器证书。然后客户端能验证服务器的CA发布的数字证书。
然而，当解决一些问题的同时，使用CAs又引入另一个问题。因为CA给许多服务器颁发数字证书，你仍然需要一些措施确保你正和你想要的服务器进行交互。为了解决这个问题，由CA颁发的数字证书通过一个特定的名称如gmail.com或者一组主机通配符例如*.google.com来识别服务器。
下面的例子将使得这些概念更具体点。下面的命令行片段，openssl工具的s_client 命令寻找通配符服务器数字证书信息。它指定443端口因为这是HTTPS协议默认使用的端口。该命令发送openssl s_client的输出给openssl x509。openssl x509命令根据 X.509 standard格式化数字证书信息。特别地，该命令请求主题，该主题包含了服务器名信息和标识CA的发布者信息。
- $ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
- subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
- issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
假设你有一个Web服务器，该服务器有由知名CA机构颁发的数字证书。你能使用下面的简单代码进行安全请求：
- URL url = new URL("https://wikipedia.org");
- URLConnection urlConnection = url.openConnection();
- InputStream in = urlConnection.getInputStream();
- copyInputStreamToOutputStream(in, System.out);
