{"node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "revisions": [{"id": "f3e3cda7-2f95-11f1-94c7-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nVerify SSL chain\r\n========================================================\r\n\r\nRun this command and paste in your signed certificate for your host.\r\n\r\n.. code-block:: bash\r\n\r\n openssl x509 -noout -issuer_hash\r\n\r\nDocument the resulting hash.\r\n\r\nThen make sure that hash exist somewhere in the certificate chain, by running this command on each cert in the chain until you find a match.  If you don't find a match you are using the wrong chain!\r\n\r\n.. code-block:: bash\r\n\r\n  openssl x509 -noout -hash\r\n\r\nYou can also use this command to get information about the SSL chain:\r\n\r\n..  code-block:: bash\r\n\r\n openssl s_client -connnect <put-domain-name-here>:443\r\n\r\n\r\n\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 9, "created": 1409773223000}, {"id": "f3e3c9ac-2f95-11f1-b840-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nVerify SSL chain\r\n========================================================\r\n\r\nRun this command and paste in your signed certificate for your host.\r\n\r\n.. code-block:: bash\r\n\r\n openssl x509 -noout -issuer_hash\r\n\r\nDocument the resulting hash.\r\n\r\nThen make sure that hash exist somewhere in the certificate chain, by running this command on each cert in the chain until you find a match.  If you don't find a match you are using the wrong chain!\r\n\r\n.. code-block:: bash\r\n\r\n  openssl x509 -noout -hash\r\n\r\nYou can also use this command to get information about the SSL chain:\r\n\r\n ..  code-block:: bash\r\n\r\n  openssl s_client -connnect <put-domain-name-here>:443\r\n\r\n\r\n\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 8, "created": 1409773189000}, {"id": "f3e3c4d2-2f95-11f1-8180-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nVerify SSL chain\r\n========================================================\r\n\r\nRun this command and paste in your signed certificate for your host.\r\n\r\n.. code-block:: bash\r\n\r\n openssl x509 -noout -issuer_hash\r\n\r\nDocument the resulting hash.\r\n\r\nThen make sure that hash exist somewhere in the certificate chain, by running this command on each cert in the chain until you find a match.  If you don't find a match you are using the wrong chain!\r\n\r\n.. code-block:: bash\r\n\r\n  openssl x509 -noout -hash\r\n\r\nYou can also use this command to get information about the SSL chain:\r\n\r\n ..code-block:: bash\r\n\r\n  openssl s_client -connnect <put-domain-name-here>:443\r\n\r\n\r\n\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 7, "created": 1409773172000}, {"id": "f3e3c0c5-2f95-11f1-9029-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nVerify SSL chain\r\n========================================================\r\n\r\nRun this command and paste in your signed certificate for your host.\r\n\r\n.. code-block:: bash\r\n\r\n openssl x509 -noout -issuer_hash\r\n\r\nDocument the resulting hash.\r\n\r\nThen make sure that hash exist somewhere in the certificate chain, by running this command on each cert in the chain until you find a match.  If you don't find a match you are using the wrong chain!\r\n\r\n.. code-block:: bash\r\n\r\n  openssl x509 -noout -hash\r\n\r\n\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 6, "created": 1409772910000}, {"id": "f3e3bc83-2f95-11f1-8193-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nCertificate expiration tracking\r\n========================================================\r\n\r\nEmail Netadmins a certificate and ask them to add it to\r\nthe BigIP for expiration tracking.\r\n\r\nThis happens automatically when using `SSL Offloading <#ssl-offloading>`_.\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 5, "created": 1396965155000}, {"id": "f3e3b83a-2f95-11f1-a904-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR <#generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR <#generate-a-private-key-and-csr>`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nCertificate expiration tracking\r\n========================================================\r\n\r\nEmail Netadmins a certificate and ask them to add it to\r\nthe BigIP for expiration tracking.\r\n\r\nThis happens automatically when using `SSL Offloading <#ssl-offloading>`_.\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 4, "created": 1396964986000}, {"id": "f3e3b3a5-2f95-11f1-949f-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. :ref:`Generate a private key and CSR <generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. `Generate a private key and CSR <generate-a-private-key-and-csr>`_\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nCertificate expiration tracking\r\n========================================================\r\n\r\nEmail Netadmins a certificate and ask them to add it to\r\nthe BigIP for expiration tracking.\r\n\r\nThis happens automatically when using `SSL Offloading <#ssl-offloading>`_.\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 3, "created": 1396964911000}, {"id": "f3e3ae73-2f95-11f1-b050-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\n.. contents::\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. :ref:`Generate a private key and CSR <generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. :ref:`Generate a private key and CSR <generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n.. _generate-a-private-key-and-csr:\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nCertificate expiration tracking\r\n========================================================\r\n\r\nEmail Netadmins a certificate and ask them to add it to\r\nthe BigIP for expiration tracking.\r\n\r\nThis happens automatically when using `SSL Offloading <#ssl-offloading>`_.\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 2, "created": 1396964845000}, {"id": "f3e3a5e1-2f95-11f1-bc2c-e86a64d24d78", "node_id": "f3e2fa1d-2f95-11f1-9208-e86a64d24d78", "user_id": "edc3f576-2f95-11f1-900f-e86a64d24d78", "author": "foxhop", "data": "SSL Certificates\r\n################\r\n\r\nWe use certificates to certify some of our domain names.\r\nThe certificate is used to build trust and prove an identity.\r\n\r\nA certificate builds trust because of the \"background check\"\r\ninvolved during procurement.  \r\n\r\nThe integrity of our identity is proven because only we have the private key.\r\nThe private key may be used to generate a CSR (Certificate Signing Request).\r\nThe CSR may be provided to a 3rd party to generate and sign us a certificate.\r\n\r\nThe sole ownership of a private key prevents both man-in-the-middle attacks\r\nand domain-name identity spoofing in regards to SSL.\r\n\r\nCreate a snakeoil cert for testing\r\n===================================\r\n\r\nEven the 'minimal' flavour of Ubuntu has *ssl-cert* package pre-installed.\r\n\r\nThe files are auto-generated and installed here:\r\n\r\n* /etc/ssl/certs/ssl-cert-snakeoil.pem\r\n* /etc/ssl/private/ssl-cert-snakeoil.key\r\n\r\nRegenerate snakeoil certs, if needed, with the following command:\r\n\r\n.. code-block:: bash\r\n\r\n sudo make-ssl-cert generate-default-snakeoil --force-overwrite\r\n \r\nRequest an internally signed cert\r\n==================================\r\n\r\n#. :ref:`Generate a private key and CSR <generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *internally* signed CV CA certificate\r\n   \r\nNetadmins will respond back with the certificate.\r\n\r\n   \r\nRequest an externally signed cert\r\n==================================\r\n\r\n#. :ref:`Generate a private key and CSR <generate-a-private-key-and-csr>`\r\n#. send an email to Netadmins:\r\n\r\n   * attach the CSR (NOT THE PRIVATE KEY)\r\n   * provide the domain name desired for certification\r\n   * ask for an *externally* signed GoDaddy CA certificate\r\n   \r\nNetadmins will respond back after procurement with the certificate.\r\n\r\n\r\n.. _generate-a-private-key-and-csr:\r\n\r\nGenerate a private key and CSR\r\n==================================\r\n\r\n#. Verify or install openssl package on host\r\n\r\n    Is openssl in your path?\r\n\r\n    .. code-block:: bash\r\n   \r\n      which openssl\r\n    \r\n    Install openssl if missing:\r\n\r\n    .. code-block:: bash\r\n    \r\n      sudo apt-get install openssl\r\n      \r\n#. Create a file using the following template.\r\n\r\n   Only the first line in the file (siteName = ) should be altered to match\r\n   the domain name intended for certification.  The filename should be the\r\n   domain.to.be.certified.tmpl, for example: secure.foxhop.net.tmpl\r\n\r\n    .. code-block:: ini\r\n\r\n       siteName = secure.foxhop.net\r\n       r = .\r\n       \r\n       [ req ]\r\n       default_bits = 2048\r\n       default_keyfile = ${siteName}.key\r\n       distinguished_name = req_distinguished_name\r\n       prompt = no\r\n       \r\n       [ req_distinguished_name ]\r\n       C = US\r\n       ST = CT\r\n       L = New London\r\n       O = Foxhop.net\r\n       OU = Foxhop.net, New London\r\n       CN = ${siteName}\r\n\r\n#. Generate a private key and a CSR for the host to be certified by using the\r\n   template that we generated above; For example (secure.foxhop.net):\r\n\r\n    .. code-block:: bash\r\n\r\n     openssl req -new -config secure.foxhop.net.tmpl -out secure.foxhop.net.csr\r\n\r\n  This process will prompt for a passphrase to protect the private key.\r\n\r\n#. Verify that the following files were created:\r\n  \r\n   * <domain>.csr\r\n   * <domain>.key\r\n\r\n#. Store these details in a pass or keepass entry:\r\n\r\n   * document the private key's passphrase in the password field\r\n   * on the \"Advanced\" attach the tmpl, csr, key, and crt files\r\n\r\nView the CSR data\r\n==================================\r\n\r\nWe may want to validate the data in a CSR before submission for certification.\r\nTo display a CSR's data to standard out, run the following command:\r\n\r\n.. code-block:: bash\r\n\r\n    openssl req -in secure.foxhop.net.csr -noout -text\r\n\r\n\r\nRemove passphrase from a private key\r\n====================================\r\n\r\nWe need to remove the passphrase from the openSSL private key for use in\r\ndeployment; Otherwise everytime the webserver is restarted it will prompt\r\nfor the keys password.\r\n\r\nExample command:\r\n\r\n.. code-block:: bash\r\n\r\n    # make a copy\r\n    cp secure.foxhop.net.key secure.foxhop.net.key.orig\r\n    # strip passphrase\r\n    openssl rsa -in secure.foxhop.net.key.orig -out secure.foxhop.net.key\r\n    # clean up orig after testing\r\n    rm secure.foxhop.net.key.orig\r\n\r\n\r\nSSL Offloading\r\n==================================\r\n\r\nSSL Offloading is the practice of using a proxy or load balancer to manage\r\nthe SSL certificates, keys, and sessions for none or many upstream nodes.\r\n\r\nThe BigIP is capable of SSL Offloading.  For SSL Offloading to occur we must \r\nload our domain's SSL certificate *AND* private key into the BigIP certificate\r\nstore.  \r\n\r\nBigIP would then gain responsibility of creating an SSL tunnel or session between\r\nthe Internet user and the edge of our corporate network. \r\nthe VIP.\r\n\r\nOptionally the traffic between the VIP and it's upstream nodes\r\n(internal network) may also be wrapped by SSL.  \r\n\r\n**when should it be used?**\r\n\r\nIf we want a central place to configure SSL for a pool of many nodes.\r\nNetadmins create a BigIP irule to manage SSL communications. The upstream\r\nnodes could run just plain HTTP (port 80).  Less complicated configuration \r\non each of the webserver nodes.\r\n\r\n**example**\r\n\r\nAn example closer to home deploying Pyramid behind nginx proxy.\r\nNginx in this case does the SSL Offloading for upstream waitress/paster nodes.\r\nThe communication between users and Nginx could be SSL wrapped while the\r\ncommunication between nginx and the upstream waitress/paster nodes could\r\nremain plain http.  Many times we can get away with this because the paster\r\nnodes are bound and listening only to localhost, thus \"firewalled\" from the \r\nrest of the network.\r\n\r\n\r\nCertificate expiration tracking\r\n========================================================\r\n\r\nEmail Netadmins a certificate and ask them to add it to\r\nthe BigIP for expiration tracking.\r\n\r\nThis happens automatically when using `SSL Offloading <#ssl-offloading>`_.\r\n\r\nDefinitions\r\n============\r\n\r\nTransitive Trust\r\n  A trusts B, B trusts C, therefore A may trust C\r\n\r\nSelf-signed Certificate\r\n  This certificate was signed by the organization who created it.\r\n \r\nSnakeoil Certificate\r\n A \"snakeoil\" self-signed cert is a great example of a singular identity\r\n certifying itself.  Outsiders may not trust a snakeoil cert because it lacks\r\n is not attached to a domain name. Snakeoil certs are excellent for testing!\r\n \"\"\"I Trust myself\"\"\"\r\n\r\nInternally Signed Certificate\r\n An \"internal\" certificate signed by the Classified Ventures (CV)\r\n Certificate Authority (CA) provides trust within the company. Employees of\r\n CV may trust an internal cert because it has meta-data and is attached to a\r\n domain name.  The Internet will not trust an internal cert because the CV CA\r\n itself was not certified by a trusted outside identity.  From inside the\r\n organization, this is a signed cert.  From outside the organization this \r\n is a self-signed cert. Internal certs are excellent for internal only\r\n servers and services!\r\n \"\"\"Employees trust the CV CA, CV CA trusts my-server,\r\n therefore employees may trust my-server.\"\"\"\r\n \r\nexternally signed certificate\r\n An \"external\" certificate is signed by a trusted identity outside of the\r\n requesting organization.  There are many trusted identities who perform\r\n this service.  This is a popular choice among Internet websites because\r\n many of the trusted external Certificate Authorities have their keys\r\n pre-loaded into web browsers. The pre-loaded key relieves friction on the\r\n end-users, they do not need to manually review or install anything.  \r\n \"\"\"You trust XYZ org, XYZ org trusts my-server, therefore you may trust \r\n my-server.\"\"\"\r\n\r\nprivate key\r\n This is the very sensitive and private portion of the certificate that\r\n must remain a secret in order for the SSL wrapped service to remain \r\n secure.\r\n", "source_format": "rst", "revision_number": 1, "created": 1396964811000}], "count": 9}