Adrian Padilla (a.k.a Grumpy Dev)

git status in linux reporting changes in all files

Adrian Padilla Vega — Tue, 12 Jun 2018 13:30:32 GMT

It has happened to me a couple times when using git on bash either natively in one of my laptops or through the Windows Linux subsystem. Note that I use Ubuntu LTS (16 and/or 18). This becomes more obvious when doing a git status for the same repository using Windows CLI/Powershell and using Bash, especially for projects created in a Windows environment. The symptoms are essentially getting no changes on staging on the Windows environment, but reporting changes on all files on staging on Linux. This is just because of the differences on how both Operating systems handle line breaks. Without complex canonicalization of your files, you can simply adjust how git handles line breaks:

git config --global core.autocrlf true

Cheers

Keys lost and found: How to recover certificate lost private keys

Adrian Padilla Vega — Wed, 03 Aug 2016 11:19:09 GMT

For whatever reason, certificate private keys keep getting lost. This is annoying specially to grumpy devs. The symptoms are clear: when you open certml.msc (machine) or certmgr.msc (user): Fortunately the answer is in certutil.exe. Here are the steps:

Localize the certificate in Powershell in admin mode. Do "cd cert:" and then recursively traverse your certificates using let's say, your thumbprint: $found = ls -r | where { $_.Thumbprint -like 'TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT'}
Get the serial number of the certificate: $found[0].SerialNumber
Grab the serial number and feed it to certutil with the following args: certutil –repairstore my SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

On success you should see some of your certificate info finishing with: "CertUtil: -repairstore command completed successfully." Then, to keep your certificate and key safe, use the Certificates module in the Microsoft Management Console or Export-PfxCertificate Powershell cmdlet to export the certificate with its private key into a .pfx file. Done! refer to the certutil documentation for more info. Happy coding!

Certificate authentication into Azure Key Vault

Adrian Padilla Vega — Thu, 31 Mar 2016 11:54:33 GMT

If you haven't, you should better Get started with Azure Key Vault first.

Azure Key Vault is amazing for keeping secrets and cryptographic keys. But I don’t understand why authentication via application secret (a string) is offered as an option. Having Azure Key Vault accessed via a secret string in your application settings is as good as having all your secrets in the config as well. Once the secret is compromised, the whole thing is vulnerable. Having a certificate as a means for authentication? Especially if you don’t check it in the same place as your secret-accessing code? And if checked in, being as a pfx whose password is shared privately off-line? Sounds a little bit better doesn’t it? I like particularly the idea of being the machine (through its certificate store) the one that has access, instead of a user with a string. At the end of the day X509 certificates are a little bit more complex that a 32 char string, right? A certificate in a machine store is not going to be accidentally be forwarded in an email to the wrong individual. Nor being left in a post it. Enough with the sales work, I’m here for the code, not for being door to door with a vacuum cleaner.

Creating the vault

As for any other exercise, some warm-up. Before working on any Azure Powershell task remember to:

Log into Azure Resource manager with the Login-AzureRmAccount commandlet.
Make sure your Azure Rm is pointing to the right place using Select-AzureRmSubscription -SubscriptionName {your subscription}

Done with the stretches, let’s create the vault.

New-AzureRmKeyVault -VaultName '{your vault name}' -ResourceGroupName '{your resource group name}' -Location 'South Central US'

Setting up an AD application and service principal to access the vault

Access to the Azure Key Vault is granted through Azure Active Directory, so you have to have an AD account you either own or have permissions to. Specifically permissions to create AD applications. This will create an application in your AD which is accessed with the certificate you just loaded into Powershell.

$certificate = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2

$certificate.Import('c:\location\certificate.cer')

$startDate = $certificate.GetEffectiveDateString()
$endDate = $certificate.GetExpirationDateString()
$credValue = [System.Convert]::ToBase64String($certificate.GetRawCertData())
$azureADApplication = New-AzureRmADApplication -DisplayName "{application name}" -HomePage "{application page}" -IdentifierUris "{application page}" -KeyValue $credValue -KeyType "AsymmetricX509Cert" -KeyUsage "Verify" -StartDate $startDate -EndDate $endDate

You can use $azureADApplication.ApplicationId to use it as “client Id” when authenticating into the key vault. Now let’s create a service principal to access the application.

$principal= New-AzureRmADServicePrincipal -ApplicationId $azureADApplication.ApplicationId

Granting access to the service principal into the Azure key vault

Finally, we have to tell the vault that the service principal is authorized to perform these operations.

Set-AzureRmKeyVaultAccessPolicy -VaultName '{vault name}' -ServicePrincipalName $principal.ServicePrincipalName -PermissionsToSecrets all -ResourceGroupName '{resource group name}'

Also use -PermissionsToKeys for grating permissions to keys as well as secrets. Full usage here Set-AzureRmKeyVaultAccessPolicy And that’s all folks.

Handling certificates for testing without storing them (and with private key!)

Adrian Padilla Vega — Fri, 11 Mar 2016 19:25:53 GMT

Just a reminder to myself and you… I do most of my unit testing involving certificates using Bouncy Castle, which is amazing. Sometimes I just want to keep my tests simpler and when I’m not working on very complex requirements I use regular self-signed certificates. I have a couple dummy ones and I like handling test certificates on its byte representation to avoid pulling them from the store. What about those times when the private key is strictly required? (Such as this time when I was constructing SAML tokens). I keep forgetting that simple certificate byte raw data does not contain its private key! It is at the end, just the certificate.

I don’t use implicitly typed local variables (var) in these examples so it is clear what is each type. Also note that the Dump( ) method is an extension used by LINQPad. I’m aware of the unnecessary conversion to Base64 string but it is how I store these certificates in my tests.

Wrong Implementation

using(X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
{
    // Getting original certificate and its representation. Using RawData
    store.Open(OpenFlags.ReadOnly);
    X509Certificate2Collection foundCertificates = store.Certificates.Find(X509FindType.FindByThumbprint, "{ your lame-ass thumbprint XD LOL }", false);
    X509Certificate2 originalCertificate =  foundCertificates[0];
    string base64Representation =  Convert.ToBase64String(originalCertificate.RawData);

    // Creating certificate from this representation
    byte[] restoredCertificateBytes = Convert.FromBase64String(base64Representation);
    X509Certificate2 restoredCertificate = new X509Certificate2(restoredCertificateBytes);
    restoredCertificate.HasPrivateKey.Dump(); // Results in false.
}

So this results in the X509 certificate object not containing its private key. The certificate is just that, the certificate. To have a certificate and private key pair, you must use another format. The most common of course being the PKCS#12 format, best known as your ol’ pal the PFX file. You obtain this not through the RawData property but using the Export method, which also returns a

Correct implementation

using(X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
{
    // Getting original certificate and its representation. Using the Export method
    store.Open(OpenFlags.ReadOnly);
    X509Certificate2Collection foundCertificates = store.Certificates.Find(X509FindType.FindByThumbprint, "{ your lame-ass thumbprint XD LOL }", false);
    X509Certificate2 originalCertificate =  foundCertificates[0];
    string base64Representation =  Convert.ToBase64String(originalCertificate.Export(X509ContentType.Pfx, "Your (not necesarily for testing) strong password"));

    // Creating certificate from this representation
    byte[] restoredCertificateBytes = Convert.FromBase64String(base64Representation);
    X509Certificate2 restoredCertificate = new X509Certificate2(restoredCertificateBytes, "Your (not necesarily for testing) strong password");
    restoredCertificate.HasPrivateKey.Dump(); // Results in true!.
}

Happy coding, happy drinking.

Getting more logs when troubleshooting assembly bindings

Adrian Padilla Vega — Sat, 20 Feb 2016 16:21:55 GMT

When having runtime assembly binding issues, in most cases the FusionLog property of the exception thrown is more than enough. However, to get more insight about the binding process to troubleshoot assembly loading exceptions or even more subtle errors such as grabbing an unexpected version of the assembly, you can use the Fusion Log Viewer: This comes with your Visual Studio tools and it is available in the developer command line (remember you gotta have a shortcut handy?). The callsign for this warrior is fuslogvw.exe. More information here.

How to get an assembly's public Token, with capital "T"

Adrian Padilla Vega — Fri, 19 Feb 2016 15:18:44 GMT

Sometimes I forget this simple fact and drives me crazy (and for those who are learning to do this for the first time). The parameters of the SN.exe (Strong Name Utility) tool, are CASE SENSITIVE, so… For getting the Public key token of a Strongly named assembly:

sn -T "Microsoft.IdentityModel.Clients.ActiveDirectory.dll"

With the T as capitalized as you can. The “straightforward” error response you get if you do -t is:

Failed to convert key to token -- Invalid assembly public key.

And that is correct because….

-t[p] 
    Display token for public key in  (together with the public key
    itself if -tp is used).
  -T[p] 
    Display token for public key of  (together with the public key
    itself if -Tp is used).

…geez, some usability please :) I promise a later post on developer usability…. Of course do this from the Developer Command Prompt, developers should always have a shortcut to this on the desktop. Grumpy dev has a shortcut. Grumpy dev is smart. Be like Grumpy dev.

Versioning 2.0

Adrian Padilla Vega — Thu, 18 Feb 2016 11:39:10 GMT

I still like our classic versioning systems, I'm an old-fashioned developer who was raised in the world of Software Products. However, a new Grumpy Dev's rant is coming up. We are not in a world of packed software anymore, with big product factories which were self-involved in their developments, and in which versioning was only to distinguish one artifact to the same one in another point of time. Today, development is highly democratized. We have publicly shared projects. We have public web services with changing API's. We have software package sharing mechanisms such as NuGet (or npm if Node.js is your gig, or pip if you are a Python snake charmer, etc.). Just having a linear (most likely time) progression of software versions is not enough in many scenarios. We have to make sense out of this digit string. Here is where Semantic Versioning comes to the rescue. In the words of Tom Preston-Werner:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

This gives more meaning to it, doesn't it? I'm taking a wild guess here by assuming that's why is called semantic versioning. Plus, in most cases you can still tell which version comes after another. Start using semantic versioning TODAY. "In order to be united as software developers, we must give meaning to our version numbers." - Abraham Lincoln.