c++ - Boost.Asio: Writing a SSL Server/Client Too many file types -
i want make simple ssl server/client couple using boost.asio. before doing have read ssl, certificates, private keys, public keys etc. used openssl generate private key (.key) , certificate (.crt). certificate self-signed.
then, started digging boost.asio samples. first tried write client. in sample verify file *.pem file. had no idea was. after searching little (googling "how convert crt pem" etc.) got .crt file .pem file since starts -----begin
, encoded in base64.
so have done writing client , using .crt file argument of ctx.load_verify_file()
. appropriate practice?
to test client, have started writing server. have 3 kinds of files, 2 of them not familiar. are:
- certificate chain file
- private key file (the 1 familiar)
- temporary dh file
in example private key file *.pem file, private key file *.key file. confused. need make conversion?
so explain me:
- what *.pem file? how can represent private key verification?
- what certificate chain file?
- what temporary dh file?
pem file
a pem file (x.509) specifies format representing public certificate, certificate chain, public key, etc. in text format. can have various extensions (.cert, .key, .pem, etc). each item base64 encoded between header , footer:
-----begin <item type>----- item data -----end <item type>-----
for instance, boost.asio ssl example's server.pem
file contains:
-----begin certificate----- miib/jccawcccqdladuqor8yctanbgkqhkig9w0baqufada7mqswcqydvqqgewjb vtemmaoga1uecbmdtlnxmq8wdqydvqqhewztewruzxkxdtalbgnvbaotbgfzaw8w ... more lines ... wub94g/gtst9ecvhrkuubn4xt1rz5do20h3vsaztirksfqpdwunybbiva0hsf6pf 287ca1cm106x0vs4dv2f2u0zsszyfoysam1pipcxdyboxa== -----end certificate----- -----begin rsa private key----- proc-type: 4,encrypted dek-info: des-ede3-cbc,9a7cf9c13224c492 w00sj2/d79lri+9lrsnqkbzwio/nbprftn3svqcuatncqowl9bnkznq2csnj8kza stal+pzayjqtijfjxecckb8tu4/apfe2v9/pxuirjzgtj9fhbajlgmpk4ywwscmq ... more lines ... g+psovlngcnfh+z4no5cb4mvntrr1nah6ifhnlrip4yfrk3xphvlkrxn6fheedge evb3xjcgsgnvqcvf5vsymzwz722xglpkk8ig3qlayom4c9rlrkmwwa== -----end rsa private key----- -----begin certificate----- miib7tccavyccqcxkhauh1ygcdanbgkqhkig9w0baqufada7mqswcqydvqqgewjb vtemmaoga1uecbmdtlnxmq8wdqydvqqhewztewruzxkxdtalbgnvbaotbgfzaw8w ... more lines ... mqk2weh6dvq1r7fwqeq1lq10qbdobbjdre9jpezwdgmthbytle6/8whujeq189pr xwzwyrvnfci+pqx832ynrh24ujwuv3wlx3jovbyybcojc05n1thaho0q7j//8hsx vs/rfhuq3muy47cv9gbsciw= -----end certificate-----
do note there other ways present certificates, such pkcs#7 , pkcs#12.
certificate chain
a certificate chain chain of certificates 1 steps through start end until certificate explicitly trusted trusted certificate authority (ca) found.
- the start of chain contains end-user certificate. certificate issued server connection being made. trusted or intermediate ca may have issued certificate.
- there may many intermediate certificates between start , end of chain. these issued intermediate ca, , issued either different intermediate ca or trusted ca.
- the end of chain contains root certificate. issued trusted ca itself. certificates trusted cas distributed web browsers , operating systems.
for example, consider if example.com
has been issued certificate alpha
intermediate ca; alpha
has been issued certificate bravo
intermediate ca; , bravo
has been issued certificate trusted charlie
ca, certificate has been distributed web browser package. example, verification is:
- does end-user
example.com
certificate havealpha
issuer? - does
example.com
certificate verifyalpha
's key? - does intermediate certificate
alpha
havebravo
issuer? - does
alpha
's certificate verifybravo
's key? - does intermediate certificate
bravo
havecharlie
issuer? - does
bravo
certificatecharlie
's key? - does root certificate
charlie
havecharlie
issuer? - does provided
charlie
certificate verify againstcharlie
certificate has been installed on system trusted ca?
dh file
the dh file contains initialization values diffie-hellman key exchange, algorithm exchanging keys on public channel while providing perfect forward secrecy. algorithm enables 2 parties generate shared key while minimizing change observer, sees entire exchange, generate same key. parameter generation can expensive, done once in advance , reused multiple key exchanges.
see openssl diffie hellman entry more details.
Comments
Post a Comment