Archives for category: Uncategorized

Today I found myself working with a group to stand up a GitHub Enterprise environment in the Azure cloud.  My specific task was to figure out how to make certificates and DNS work with the new instance.  Before purchasing a certificate from a public certificate authority, I wanted to make it work with a free certificate signed by our corporate certificate authority.  When I attempted to upload the certificate signed by our corporate CA and key in the GitHub Enterprise management console, I received an error that said “The certificate is not signed by a valid issuer.”  This basically meant the linux server that the GitHub Enterprise application was running on needed me to import our corporate root and intermediate certificates into the server’s certificate store.  Below is what I did to make accomplish this task.

When we provisioned the GitHub Enterprise server in Azure, a DNS name was automatically assigned to the instance that resolved to a dynamic public IP.  The fully qualified domain name (FQDN) looked something like

‹instance name›.‹data center location›.cloudapp.azure.com

Since you probably don’t own the azure.com domain, you need to pick a new DNS name in a domain that you own for example: github.‹your company name›.com  Once a name is selected, add a CNAME entry to your external and internal DNS that points the name you picked to the name that was assigned when generated the GitHub Enterprise instance.

Next, generate a private key and certificate signing request file (CSR) for github.‹your company name›.com  I did this using our load balancer but you could easily use OpenSSL to do the same thing.  Once you have the CSR and private key files, submit the CSR file to your enterprise certificate authority in order to generate a signed certificate for github.‹your company name›.com.

Create a new text file that concatenates the certificate you generated with the root and intermediate certificates from your CA.  The proper order is site certificate, intermediate certificate, root certificate.  Save the file as ‹my certificate and cert chain›.cer  Also, save the root certificate to a file named rootCA.crt and the intermediate certificate to a file named interCA.crt.

Next, SCP on port 122 to the DNS name automatically assigned when the instance was created and upload the root and intermediate certificates.  To do this, you might need to generate an SSH key on your device and add it in the GitHub Enterprise management console.

scp -P 122 ‹folder location›/rootCA.crt admin@‹instance name›.‹data center location›.cloudapp.azure.com:/home/admin

scp -P 122 ‹folder location›/interCA.crt admin@‹instance name›.‹data center location›.cloudapp.azure.com:/home/admin

Next, SSH on port 122 to the DNS name automatically assigned when the instance was created and import the root and intermediate certificates into the server’s certificate store.

ssh-p 122 admin@‹instance name›.‹data center location›.cloudapp.azure.com

ghe-ssl-ca-certificate-install -c rootCA.crt

ghe-ssl-ca-certificate-install -c interCA.crt

Once the root and intermediate certificates have been imported into the server certificate store you should be able to upload the ‹my certificate and cert chain›.cer certificate and private key in the GitHub Enterprise management console then click save.  The server processes will restart during which the website will be down for a brief period of time. After it is back up, access the website in a browser and view the certificate to verify that it is valid for github.‹your company name›.com

Lastly, in the management console, update the hostname field with github.‹your company name›.com and click the test button.  Verify that it passes the A record and SSL tests.  If it does, click save.  After the services restart you should be able to access https://github.‹your company name›.com in a browser from a corporate device without receiving a certificate error.

Advertisements

Working on the network infrastructure side of IT has its good days and bad.  A good day consists of making configuration changes or performing upgrades that go unnoticed by end users.  A bad day is when you make a change that takes the entire network down.

Recovering from a major outage is tough.  You get the pleasure of reliving the incident while answering questions from upper management.  Performing a root cause analysis typically leads to more questions than answers.  Your confidence takes a hit and you start to question yourself when making basic daily operational changes.  My colleague jokingly compared this to PTSD.  There is also a period of time when the network is automatically blamed for any new issues that occur.  This lasts until another system breaks and it becomes the culprit for all issues going forward.

The intention of this blog is to share my IT experiences to help others in the industry have more good days then bad.