You are on page 1of 7

WHITE PAPER

:
SSL FOR APPS
BEST PRACTICES FOR DEVELOPERS

White Paper

SSL for Apps
Best Practices for Developers

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 End-entity Certificate Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusion . . 3 Chain Building . . . . . . . . . . . . . . . . . . . . 6 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .White Paper: SSL for Apps Best Practices for Developers SSL for Apps Best Practices for Developers Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Intermediate Certificate Checks . . . . . .

or they may fail to return certificates that are needed to build a chain. 3 . For more than a decade. Misconfigured web servers may also return more certificates than necessary to build a chain. Chain Building During the SSL handshake. Note: If a self-signed root certificate (defined as a certificate whose Issuer Name is the same as its Subject Name) is returned by the server. The chain can be built either with authorityKeyIdentifier/ subjectKeyIdentifier (AKI/SKI) extension values (the AKI value in a certificate should match the SKI value in the certificate that signed it). The most significant challenge facing the SSL ecosystem is not a technological flaw or limitation. All SSL Client non-browser applications should follow all the practices in this document to ensure the high level of authentication. authentication. These issues result from flawed implementations of SSL in the applications or in SDKs or APIs used by the applications. the server will return one or more certificates to the client to build a chain of trust. stable platform for ensuring security and trust online. As mobile device adoption increases. This paper lists necessary steps to take to create a stronger. Don’t assume that the certificates for this chain are returned in any particular order. This is an issue that needs to be addressed because today more and more services are offered through non-browser application interfaces. enabling the growth of e-commerce and other industries. Try to build a certificate chain to determine which certificate is the end-entity SSL certificate. This information may help you locate certificates in the chain that are not returned by the server. and integrity.White Paper: SSL for Apps Best Practices for Developers Introduction SSL/TLS is a core enabling technology that is critical for securing communications. more trustworthy SSL implementation. but rather the way it is being implemented and the practices around it. the use of these applications will increase and thus the impact of these security implementation shortcomings will grow as well. or with Issuer Distinguished Name / Subject Distinguished Name values (the Issuer Distinguished Name value in a certificate should match the Subject Distinguished Name value in the certificate that signed it). Several University researchers have recently published reports indicating widespread errors and shortcomings in non-browser applications that act as the client of an SSL/TLS connection. it should be ignored. No certificate should be trusted simply because the server returns it. Often but not always these applications are designed for use on mobile devices. SSL has provided a solid. that entry will indicate a protocol and location where you can obtain the issuing certificate. SSL is a fundamentally sound technology that provides confidentiality. If a certificate contains a caIssuers entry in its authorityInfoAccess extension. confidentiality and integrity promised by SSL are achieved.

html). It is extremely risky to trust all SSL certificates that chain up to all root certificates in the platform’s trust store. Note: –– Newer certificates will not contain a Common Name field at all. and is signed by an intermediate certificate with a specific Common Name. This practice is risky because it expands the pool of certificates that you will trust. Do not assume that the string is null-terminated. A more convenient practice is to allow any end-entity SSL certificate that is signed by a particular trusted intermediate certificate. IDN certificates should contain a punycode version of the Unicode domain name in the Common Name or SAN field. unicode.mail. A good compromise would be to require that the end-entity SSL certificate chains up to a particular trusted root.example. Think carefully about which certificates you will ultimately trust. perform these checks: 1. –– The certificate should be rejected if it contains more than one Common Name value. Pick only one trusted root. rather they will use SAN values.org/draft/faq/idn. however the downside to this type of implementation is that your application will break when the certificate is renewed or replaced. for example). although at some point even the intermediate certificate will be renewed or replaced. including UTF-8. End-entity Certificate Checks When comparing strings extracted from certificates. It is quite secure to require the server to return a particular end-entity SSL certificate. the root certificate’s public key signed the intermediate certificate. or if the address to which the connection was created does not match the Common Name or any SAN values. –– Don’t assume that the certificate contains a Common Name.). More information about building certificate chains can be found in Section 6 of RFC 5280.example.com or *. Also note that strings may be encoded in different types. etc.White Paper: SSL for Apps Best Practices for Developers Cryptographically verify that the chain from end-entity certificate to trusted root certificate or intermediate certificate is valid (that is. but avoid trusting all end-entity certificates that chain up to that root. 4 . possibly beyond what you intend. –– Take into account proper wildcards (*. Verify that the fully-qualified domain name or IP address to which the connection was created appears in either the Common Name field of the Distinguished Name. note that they are represented in the certificate as a byte length. validate that the intermediate’s public key signed the end-entity certificate. –– Take into account International Domain Names (IDNs) (see http://www. followed by that number of bytes. For the end-entity SSL certificate. or in one of the Subject Alternative Name (SAN) extension values. com.

The certificate must contain a keyUsage extension.White Paper: SSL for Apps Best Practices for Developers 2. If the certificate contains an extKeyUsage extension. check that it appears in the certificatePolicies extension. The certificate must contain the crlDistributionPoints extension or the authorityInfoAccess extension with an AccessMethod value of idad-ocsp. or both (fallback from one method to the other). If the certificate contains a keyUsage extension. 5 . If you can’t be sure that your application has an accurate time source. or has just expired in the last few days. 6. with the cA flag set to true. you may wish to err on the side of caution and accept a certificate that will not be valid for a few more days. 2. Note that date/ times are represented in GMT. or if it contains special purpose OIDs. up to and including the trusted intermediate certificate (if the intermediate is your trust point). perform these checks: 1. If you can’t be sure that your application has an accurate time source. these may be used until their validity end date instead of making another request for a CRL or OCSP response. 3. For each intermediate CA certificate in the chain. and less than the notAfter time in the certificate. 8. including UTF-8. If any other extension is marked ‘critical’. 3. 4. the application must be able to recognize and understand the value of the extension. OCSP. The current date/time must be greater than the notBefore time in the certificate. If the client application caches CRLs or OCSP responses. If a particular policy is expected. Do not assume that the string is null-terminated. and less than the notAfter time in the certificate. the cA flag must be set to false and the pathLenConstraint must be set to 0. the digitalSignature and keyEncipherment bits must be set. with the keyCertSign bit set. 7. The status of the certificate can be verified by checking CRL. If the certificate contains a basicConstraints extension. Also note that strings may be encoded in different types. Verification must result in a positive determination that the certificate has not been revoked. the extension value must be either the special anyExtendedKeyUsage value. The certificate must be rejected if it contains any critical extensions that the application does not recognize. you may wish to err on the side of caution and accept a certificate that will not be valid for a few more days. The current date/time must be greater than the notBefore time in the certificate. followed by that number of bytes. Note that date/ times are represented in GMT. Intermediate Certificate Checks When comparing strings extracted from certificates. 5. or has just expired in the last few days. then id-kp-serverAuth must be included. The certificate must contain a basicConstraints extension. note that they are represented in the certificate as a byte length.

browser developers. Symantec is leading the way with world-class security and authentication practices. we can ensure that people have the confidence they need to connect online now and in the future. By working together as an industry to do the right thing. 7. the application must process the constraints for all certificates in the subtree beneath it. enforcing rigorous security practices. check that it appears in the certificatePolicies extension. The certificate must contain the crlDistributionPoints extension or the authorityInfoAccess extension with an AccessMethod value of id-ad-ocsp. Yet unless certain checks are performed. If the client application caches CRLs or OCSP responses. The status of the certificate can be verified by checking CRL. provides strong confidentiality and integrity for communications. If the nameConstraints and/or policyConstraints extensions are present. an attacker can intercept and modify data without detection. and it will continue to provide excellent protection against evolving cyber security threats. If any other extension is marked ‘critical’. Verification must result in a positive determination that the certificate has not been revoked. they may be used until their validity end date instead of making another request for a CRL or OCSP response. OCSP. and with what certificate authorities. as well as authentication of one or both endpoint identities. consumers and all other stakeholders can do to help build a more robust security ecosystem. 6. Conclusion The SSL/TLS protocol. All SSL Client non-browser applications should follow all the practices in this document to insure the high level of authentication. or both (fallback from one method to the other). and adopting stronger security standards. If a particular policy is expected. when properly implemented. The normative reference for this document is RFC 5280. maintaining an agile infrastructure. SSL has been the key to trust on the Internet for more than a decade. 6 .White Paper: SSL for Apps Best Practices for Developers 4. customers. The certificate must be rejected if it contains any critical extensions that the application does not recognize. the application must be able to recognize and understand the value of the extension. confidentiality and integrity promised by SSL. 5.

S. the Symantec Logo.com/socialmedia. About Symantec Symantec protects the world’s information and is the global leader in security.com or by connecting with Symantec at: go.S. and interactions gives our customers confidence in a connected world. backup. please visit our website. CA 94043 USA 1-866-893-6565 www. and other countries.S. UID: 131/10/13 . Symantec. Symantec World Headquarters 350 Ellis Street Mountain View. More information is available at www.com/ssl To speak with a Product Specialist in the U. and availability solutions.symantec. 1-866-893-6565 or 1-650-426-5112 To speak with a Product Specialist outside the U.symantec.symantec. Our industry-leading expertise in protecting data. identities. For specific country offices and contact numbers.com Copyright © 2013 Symantec Corporation.White Paper: SSL for Apps Best Practices for Developers More Information Visit our website http://www. All rights reserved. Other names may be trademarks of their respective owners. Our innovative products and services protect people and information in any environment – from the smallest mobile device to the enterprise data center to cloud-based systems. and the Checkmark Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.symantec.